wkoy cyak s6b7 i048 0gsa 46b9 o68a x9xd qymc ocgi
tceic.com
学霸学习网 这下你爽了
相关标签
当前位置:首页 >> >>

The Reuse of Uses in Smalltalk Programming

标签:香料 s6b7 银河娱乐场博彩


The Reuse of Uses in Smalltalk Programming
MARY BETH ROSSON and JOHN M. CARROLL Virginia Polytechnic Institute and State University

Software reuse, a long-standing and refractory issue in software technology, has been specifically emphasized as an advantage of the object-oriented programming paradigm. We report an empirical study of expert Smalltalk programmers reusing user interface classes in small graphical applications. Our primary goal was to develop a qualitative characterization of expert reuse strategies that could be used to identify requirements for teaching and supporting reuse programming. A secondary interest was to demonstrate to these experts the Reuse View Matcher—a prototype reuse tool—and to collect some initial observations of this tool in use during reuse programming. We observed extensive “reuse of uses” in the programmers’ work: they relied heavily on code in example applications that provided an implicit specification for reuse of the target class. We called this implicit specification a “usage context.” The programmers searched for relevant usage contexts early. They repeatedly evaluated the contextualized information to develop solution plans, and they borrowed and adapted it when the sample context suited their immediate reuse goals. The process of code development was highly dynamic and incremental; analysis and implementation were tightly interleaved, frequently driven by testing and debugging. These results are considered in terms of the tradeoffs that inhere in the reuse of uses and the teaching and tool support that might improve the efficiency and accuracy of this approach to reuse. Categories and Subject Descriptors: D.1.5 [Programming Techniques]: Object-Oriented Programming; D.2.6 [Programming Techniques]: Programming Environments; D.2.m [Programming Techniques]: Miscellaneous—reusable software; H.5.2 [Information Interfaces and Presentation]: User Interfaces—training, help, and documentation General Terms: Documentation, Human Factors, Languages Additional Key Words and Phrases: Debugging into existence, example-based learning, reuse of uses, Smalltalk, usage context

1. INTRODUCTION Code reuse is an issue with a long and unsatisfactory record in software technology [Biggerstaff and Perlis 1989]. The driving logic has always been
This work was done while the authors were on the research staff of the IBM T.J. Watson Research Center. The authors were assisted in the development of the RVM, as well as the example applications and their documentation, by Christine Sweeney and Dan Walkowski. A preliminary report of this article was given at ECOOP ’93. Authors’ address: Virginia Polytechnic Institute and State University, Department of Computer Science, 562 McBryde Hall, Blacksburg, VA 24061-0106; email: {rosson; carroll}@cs.vt.edu. Permission to make digital / hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and / or a fee. ? 1996 ACM 1073-0516/96/0900 –0219 $03.50
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996, Pages 219 –253.

220

?

Mary Beth Rosson and John M. Carroll

clear and attractive: it should be faster to patch in a module than to create it from scratch. But this appealing image has been difficult to realize. Designing code that is both general enough to be useful in a variety of contexts, and specific enough to fulfill actual needs is a demanding task not well supported by current design methodologies and representations [Biggerstaff and Richter 1987; Meyer 1987]. Even if reusable code is available, management must provide developers effective encouragement to reuse rather than redevelop functionality (e.g., programmers are paid to write code, not to reuse code another programmer has written). With the object-oriented software paradigm, the phoenix of reuse has arisen with renewed hopes and bolder ambitions. Object-oriented design techniques produce collections of highly abstract, encapsulated modules (classes) which are organized into generalization hierarchies. Thus, just creating an object-oriented design enforces one demanding prerequisite for pervasive reuse: a library of modular components with standard interfaces, organized by the specificity of the functionality provided. Some of the most distinctive innovations of object-oriented software, such as inheritance and polymorphism, can be seen as serving the reuse vision. Polymorphism, for example, allows a programmer to send the same message to instances of different classes with different effects; code including a polymorphic message can thus be reused in new situations by manipulating the class of the object receiving the message. And while the promise of the object-oriented paradigm for software reuse has been asserted more than demonstrated, empirical evidence confirming such claims is beginning to appear [Lewis et al. 1991]. Though object-oriented software provides an important new opportunity to further a software practice of reuse, many questions and challenges remain open. Object-oriented design lends itself to the production of modular components, but methodologies for the design of reusable classes remain an open issue [Johnson and Foote 1988; Meyer 1988]. Even programmers predisposed to reuse code may need help in recognizing good opportunities for reuse; as class libraries have increased in size, researchers have begun to apply a variety of information retrieval technologies to the problem of identifying candidates for reuse [Bellamy and Carroll 1990; Helm and Maarek 1991; Prieto-D?az 1991; Raj and Levy 1989; Singley and ? Carroll 1990]. Once a promising class has been identified, programmers may need help during the reuse programming process, analyzing whether and how to reuse a class, determining whether to incorporate it as-is or specialize it, and developing the code needed to exercise it in a particular programming context [Fischer 1987]. This final aspect of reuse—the process of adapting old code to new purposes—is the focus of the work reported here. Despite the tremendous interest in facilitating reuse, very little is known about how programmers go about reusing code. A comprehensive analysis of a single programmer reusing personal code is provided in Lange and Moher [1989]; however, their analysis may be relevant only to situations in which the reuse programmer either wrote the to-be-reused code or was
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

221

familiar with it from prior reuse (see also Detienne [1991]). An evaluation ? of the usefulness of providing example solutions to student programmers working on coding problems is provided in Redmiles [1993], but there the reuse was at the level of subroutines, not classes, and the focus of the analysis was on the variability of the code produced, rather than the process of developing the code. The work reported here complements this prior research on reuse programming by providing an in-depth study of Smalltalk experts reusing user interface classes developed by other programmers. We chose to study the reuse of user interface classes because they have been the focus of a number of rich and extensible class libraries (e.g., InterViews [Linton et al. 1989]). We hoped that our analysis would highlight some of the strategies that expert programmers recruit in tackling reuse problems; once these expert strategies are documented, they can be recruited in the training of less experienced programmers. We also hoped to highlight problematic aspects of the experts’ reuse programming, and exploit them as grist for ideas about how to better facilitate reuse, either through tools or the provision of appropriate information sources. A major question in this empirical study concerns the role of example applications as a source of implicit reuse information. Like Redmiles [1993], we believe that concrete examples are an important vehicle for learning about new abstractions. For several years we have been studying the role of examples in learning and using object-oriented designs and code [Carroll et al. 1990; Rosson et al. 1990; 1991]; this observational study of Smalltalk reuse can be seen as a slice of that larger effort. The reuse task setting we developed for the study included example applications of the user interface components already in use, so that we could observe the experts’ efforts to locate and reuse the usage information embedded in these examples. A secondary goal of the work was to present Smalltalk experts with a prototype tool providing example-based reuse documentation, the Reuse View Matcher. The design of this tool is based on analytic work that combined our prior studies of Smalltalk learning with a task analysis of Smalltalk reuse [Carroll and Rosson 1991]. Thus although our prime goal was to characterize the experts’ normal reuse strategies, we also wished to examine their reactions to and experiences with this tool when it was introduced into the work environment. 2. THE REUSE SETTING This is an exploratory study of critical incidents in the reuse programming process [Flanagan 1954]. That is, we are categorizing episodes of reuse practice in which something goes notably well or bad. This kind of analysis does not seek to produce a detailed description of the routine phenomena of reuse; rather it focuses on potential high-leverage phenomena in the current practice to identify areas of opportunity for the design of new tools and techniques. It is particularly appropriate in a practical domain like
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

222

?

Mary Beth Rosson and John M. Carroll

programming which is characterized by large differences among individual programmers and in which the goal of developing a comprehensive, descriptive theory is largely disjoint with the goal of developing new tools and techniques to address specific, observable strategies or problems pertaining to productivity and effectiveness. The nature of this exploratory study constrained the methods that were appropriate. Because we were interested in reuse practice, it was paramount that we study professional programmers—not students enrolled in an object-oriented programming course—and that we study our participants working on problems that were meaningful to them. However, because the time of such professionals is valuable, and because we wanted to observe their behavior in a setting that was at least loosely controlled, we developed reuse projects that could be completed in a relatively short amount of time. Because our primary interest was in established practice, we constructed problems that could be solved within the experts’ standard programming environment. We recruited four professional programmers as volunteer participants. Each had been programming in the Smalltalk/V? PM environment [Digitalk 1989] for over two years, and had over 10 years of experience programming in other languages. All had worked on prototyping interactive applications in Smalltalk, largely on building components for advanced user interfaces (e.g., multimedia objects, direct manipulation techniques, visual programming). 2.1 Smalltalk/V? Programming Tools The Smalltalk/V environment contains a rich set of programming tools. Central is the Class Hierarchy Browser (CHB). This tool supports the browsing, editing, and creation of classes; all computation in Smalltalk is carried out by objects, and every object is an instance of a class. An object is an encapsulation of state (represented by instance variables) and behavior (represented by methods); both state and behavior can be inherited from a class’s superclasses. Smalltalk programming typically involves the creation of new classes, such that instances of the class are connected to other objects (via their instance variables), and are able to respond to a variety of messages (implemented as methods in a class or its superclasses). Using a CHB, programmers navigate within an inheritance hierarchy to access classes, and then are able to view, edit or create class definitions and method code. Other important tools are inspectors, debuggers, and workspaces. In an inspector, a programmer can view and edit the internal state (i.e., the instance variables used to connect objects together) of an instantiated object. Debuggers can be used to examine the state of a running application’s objects, or to step through the messages passed among these objects. A debugger is typically invoked when an error is encountered (e.g., an object receives a message it does not understand) or when the programmer deliberately sets a breakpoint in a method. Workspaces are text areas in
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

223

which arbitrary pieces of code can be evaluated; they are often used to create and experiment with instances of classes. 2.2 The Reuse Tasks We developed two reuse projects that approximated the application prototyping activities these programmers carry out in their normal work environment— both projects involved an enhancement to the user interface of an already-written interactive application. The projects were simple but nontrivial examples of Smalltalk applications; in debriefing sessions after the experiment, all of the programmers judged that these were representative programming tasks. The instructions to the programmers specified the class they were to use in making the enhancement. Clearly this removes one important subtask of reuse—locating candidate classes in a library— but because our main interest is in the programming effort directed at reuse, it seemed an appropriate simplification. We elected to focus on the reuse of user interface components for two reasons. First, we had access to Smalltalk programmers with experience in this area. Second, much of the interest in the object-oriented programming community has focused on the reuse of interactive components— user interface “widgets” are often time-consuming to build from scratch and the concepts and technology required to generate such components are evolving rapidly. 2.2.1 Color-Mixer. One of the projects consisted of an enhancement to a color-mixer. The color-mixer converts RGB values input by the user to create custom colors; these colors are stored in and retrieved from a database of named colors. The original application has three buttons for red, green and blue (see Figure 1); clicking one of these buttons brings up a dialog box in which the user types an integer to manipulate a color component. The color being edited is displayed as a “swatch,” and is flanked by the list of saved colors. Users can select colors from the list, as well as adding and deleting colors. Because everything in Smalltalk is an object, and because objects typically inherit much of their functionality, it is difficult to characterize the “size” of applications. However, the most important objects in the colormixer are instances of six classes: ColorMixer, ColorMixWindow, ButtonPane, ListPane, GraphPane and Dictionary (see Figure 2(a)). The last four of these classes are part of the standard library. The number of methods in these six classes ranges from six to 54, with an additional 118 to 338 inherited methods. The programmer’s task was to create horizontal sliders in place of the buttons (see Figure 1). No information was provided concerning the appearance or functionality of the slider, only that they were to use the new class HorizSliderPane. A typical solution involves the editing of the openOn: method in ColorMixWindow (this is the method that creates and initializes the windows and subpanes, and the button creation code must be replaced
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

224

?

Mary Beth Rosson and John M. Carroll

Fig. 1. The color-mixer project. On the left is the original version using buttons to enter rgb values; on the right is the version enhanced to use sliders.

with analogous code for the sliders), and the addition of four new methods (to handle activity in each of the sliders, and to draw any given slider). The class library also included a football analysis program that uses five instances of HorizSliderPane to manipulate defensive player characteristics (e.g., speed, age, height); the predicted consequences of the characteristics (e.g., sacks, interceptions, tackles) are graphed in a separate pane. This example application uses five main classes: FootballAnalyst, HorizSliderPane, BarGraphPane, AnalysisWindow, and Dictionary; only Dictionary is part of the standard library. The method count for these classes ranges from five to 33, with from 118 to 363 inherited methods. 2.2.2 Library. The other project consisted of enhancements to a library acquisitions application. This application manages a hierarchical collection of book categories (e.g., Computer Applications broken into Electrical Engineering, Aerospace Engineering, etc.); categories are annotated with information about acquisitions (e.g., number of books, titles). Hierarchical structure is conveyed via an indented list (see Figure 3), and users manipulate the categories by selecting a list item and making menu selections. In this way, they can add and delete categories, rename categories, and browse and edit the acquisitions information.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

225

Fig. 2. The project classes. On the left are the major classes used in the color-mixer project and the football example; on the right are the classes for the library and the org chart. Indentation indicates a subclass relationship; classes from the example application are in italics, the reuse target class in bold-italics.

The library project also uses five main classes: Library, NetworkNode, ListPane, NetworkConnection and LibraryWindow; only ListPane is part of the standard hierarchy. The Library class inherits from two novel superclasses, Network and Hierarchy (see Figure 2(b)). The method count for these five classes ranges from 4 to 54, with from 118 to 319 inherited methods. Programmers were asked to enhance this project by using the new class HierarchyPane; again, they were told nothing of the appearance or functionality of the target class. An instance of this class is able to graph a hierarchical network of nodes (see Figure 3). It also can identify nodes or connections selected via a mouse click. Finally, the subpane allows users to name nodes by typing directly onto the graphed elements. As in the other project, the class hierarchy included a sample usage context for HierarchyPane—an organization chart, in which the nodes correspond to employees, and in which employees of various job descriptions (e.g., staff member, secretary, visitor) can be added to the hierarchy, given names, reassigned, and given project descriptions. The org chart application uses seven main classes: OrgChart, OrgChartWindow, HierarchyPane, NetworkNode, NetworkConnection, Node, and TextField; none of these are part of the standard hierarchy. Both OrgChartWindow and HierarchyPane inherit from novel superclasses. These classes have from 1 to 37 local methods, and 118 to 442 inherited methods.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

226

?

Mary Beth Rosson and John M. Carroll

Fig. 3. The library project. On the left is the original version using a list pane to present and select book categories; on the right is the version enhanced to use a graphical hierarchy.

HierarchyPane differs from HorizSliderPane in that much of its functionality is inherited from its superclass NetworkPane. Further, it was designed to work in concert with a number of other classes unfamiliar to the programmers: HierarchyWindow, Node, NetworkNode, and NetworkConnection; HorizSliderPane is a relatively “standalone” component. As a result, the simplest solution to reusing HierarchyPane is to create a new LibraryWindow class as a subclass of HierarchyWindow—thereby inheriting the ability to draw, select, and name nodes in the graph—rather than revising the code in the original class. We expected that the programmers might elect to reuse HierarchyPane through inheritance, and that we might learn something from their deliberations as they did so. If a new library window class is created, the solution then requires the transfer and updating of five methods from the original LibraryWindow class (the methods for adding, removing and showing acquisitions for a selected category, the method defining the menu, and the openOn: method). 2.3 Procedure Two programmers completed each of the reuse projects. Following these initial sessions, each programmer also completed the other project, but using a Smalltalk environment containing a prototype reuse tool. These
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

227

second sessions will be described later when we describe this tool and report our observations of its use. The programmers were read brief instructions at the beginning of each session describing the application they were to enhance, and identifying the class they were to reuse in making this enhancement. They were told that they were not expected to spend “more than a couple of hours” on the project and that they should not worry if they did not complete it in this amount of time. Finally, the programmers were asked to “think aloud” while they worked, to vocalize their plans and concerns as they worked as much as possible without interfering with their activities [Ericsson and Simon 1980]. After hearing these instructions, the programmers were given an introduction (approximately 20 minutes) to the application they would be enhancing. This involved going over a hierarchical view of the major application classes, a design diagram of application objects and their connections, descriptions of typical interaction scenarios, as well as a code “walk-through” of these typical scenarios. The intent was to make the programmers familiar enough with the project application that their problem-solving efforts would focus on the reuse problem and not on understanding how the original application worked. No information other than the name was provided about the user interface class to use in making the enhancement. During the reuse tasks, programmers worked at their own pace. The experimenters took notes and made videotapes of the programming activity on the display, occasionally prompting the programmer to comment on a plan or concern. The experimenters also intervened on a few occasions to answer questions concerning the application being enhanced. The videotaped commentary and programming work were later analyzed into activity structures annotated with timing information and verbal comments. The programmers were debriefed following their second sessions. 3. THE REUSE OF USES Most discussions of reuse assume a class or group of cooperating classes as the unit of reuse. Thus, design methodologists articulate characteristics of reusable classes [Johnson and Foote 1988; Meyer 1988] and tool builders develop techniques for classifying and retrieving useful classes [Helm and Maarek 1991; Raj and Levy 1989]. The dominant metaphor is “construction”—the programmer finds parts that can be reused, modifies them as necessary and connects them together (e.g., see Cox [1986; 1987]). Our observations suggest that the reusable abstraction itself is often just a piece of the overall picture. The programmers we observed spent little time analyzing or working directly with the classes we asked them to reuse. Instead, they reused the components indirectly, through the analysis and assimilation of the code using the component in example applications. We call this implicit reuse specification a usage context, and we call the programmers’ reliance on such a context the reuse of uses.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

228

?

Mary Beth Rosson and John M. Carroll

In the following we first provide an overview of the reuse sessions in terms of both the solutions developed by the programmers, and the process of developing these solutions. We then elaborate on incidents which help to characterize the ways in which these experts exploited existing usage context in solving their reuse problems. In most cases, the incidents refer to individual programmers, but they combine to offer an overall picture of the reuse programming we observed. Our observations are organized into a high-level task analysis of the reuse programming activities: finding a usage context, evaluating it for purposes of reuse, and debugging it into a state that meets the project’s reuse goals. 3.1 Overview Figure 4 contains four graphs depicting the major chunks of the solution process for each programmer. Although our goal in this work was not to produce a normative account of reuse programming, these panels do reveal a similarity across programmers in the gross structure of the reuse activities. After spending a few minutes browsing the class they had been asked to reuse, the programmers initiated a process of incremental code development. The first step in each case was to open a new version of the project window containing an instance of the target class. Some of the programmers had difficulty succeeding in this first step, but all eventually succeeded at opening the new version of their window. They then began adding pieces of functionality, refining the appearance of the user interface component, making it interactive, and updating relevant menus. 3.1.1 Color-Mixer Solutions. The two solutions to the color-mixer problem involved the creation of a new openOn: method which instantiated three HorizSliderPane instances in place of the three original buttons. The solutions also included creation of a draw: method in the window used in drawing the slider, and modification of the code used to handle selections in the color list such that it updated the value and appearance of the sliders appropriately. P1 and P3 (i.e., programmer #1 and #3) varied in how they managed the three sliders’ responses to mouse activity: P1 created three separate analogs of the sliderActive: method used by AnalysisWindow to process the five football sliders, while P3 developed a single sliderActive: method that contained a test to determine which of the three sliders was receiving input. However, in both cases, the overall reuse task was broken down into getting one slider to work, and then duplicating this for the other two. 3.1.2 Library Solutions. The solutions to the library problem reflected a reuse-by-inheritance strategy. As the activity graphs for P2 and P4 indicate (see Figure 3), these programmers created a new type of project window as a subclass of HierarchyWindow. Because HierarchyWindow contained a usage context for instantiating and manipulating a HierarchyPane, they were thus able to reuse HierarchyPane through inheritance. P2 used the existing methods in the superclass to add, remove and rename
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

229

Fig. 4. Programming activity graphs. The four panels summarize the gross structure of each programmer’s reuse activities. The times identify when each subtask was initiated; the indentation signifies our judgment that some activities can be viewed as components of higher-level efforts.

the nodes in the library graph, changing only the names of the items on the menu, and installing the one function (show acquisitions) specific to the library application. As a result, however, one of the inherited functions (add new category) was not exactly correct—it added elements to the library network, but only in the most generic way (this error was not
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

230

?

Mary Beth Rosson and John M. Carroll

apparent in the programmer’s limited testing of his solution). P4 followed a more conservative strategy, copying each menu function from LibraryWindow and updating it to work within the new (inherited) window context. The activity graphs for P2 and P4 also chronicle these programmers’ initial efforts to instantiate a HierarchyPane as a component of the original library window, followed by their subsequent decisions to move the LibraryWindow class into the NetworkWindow hierarchy. In both cases, this decision was made after the HierarchyPane had been successfully instantiated, when the programmers moved on to the (more complex) step of developing the code for node selection and manipulation. Of note is that P4 spent over an hour attempting to incorporate HierarchyPane as a component of LibraryWindow, but then spent only about 15 minutes developing his subclass-based solution. 3.2 Finding a Usage Context As described above, we intentionally “seeded” the Smalltalk hierarchy with example applications that used HorizSliderPane and HierarchyPane. This is a common situation in Smalltalk—most of the standard classes are used by the tools that make up the interactive environment, and new classes are often introduced as part of a new application or tool. The programmers were not told about the example applications because we wished to observe whether and how they located them. Smalltalk assists programmers in locating code that might be making use of a class by providing a “senders” function: given a candidate message in a class under investigation, the system will find all code in the system that includes this message string. Because of polymorphism there is no guarantee that the resulting code will contain a use of the class under investigation—many classes may implement a message of the same name, and the senders analysis cannot discriminate among these. The programmers appeared to be familiar with the senders function, and it played a key role in locating usage contexts. As can be seen in Figure 4, all of the programmers used the senders function to find code referring to messages implemented by the target class, most very early in their work. The comments of P2 reflect his immediate goal to locate a usage context. His very first verbalization was “Let’s see if anybody else uses this . . . Applications . . . let’s see who does this” (in these protocol fragments, we use the convention “ . . . ” to represent pauses in an utterance). Interestingly, P4 came across the NetworkWindow subhierarchy accidentally in his first few minutes of work, momentarily confusing HierarchyWindow with HierarchyPane. However, although he browsed a few HierarchyWindow methods at this point, he quickly discounted its relevance to his task, “Ok, not much of a similarity between the two.” Ten minutes later, he rediscovered HierarchyWindow as a sender of the HierarchyPane method textField, with a dramatically different reaction: “Oh, so you already have this thing solved!” Our observations suggest that there is more to locating a relevant usage context than just using the Smalltalk senders query. When P1 was asked
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

231

why he decided to investigate AnalysisWindow (containing usage context for HorizSliderPane), he responded: “Because it was the sole sender of a couple of interesting methods” (our italics). This implies that he was applying a heuristic in making senders requests; some messages are more “interesting” than others. He may have been using naming cues to assess the criticality of a message (e.g., drawSlider and sliderActive: attracted a lot of attention in the ColorMixer project). Similarly, P2 first asked for senders of setUpGrid, a message name that at once seems unusual (thus minimizing the false alarms from polymorphism) and critical to the pane’s drawing mechanism. As P2 discovered, however, setUpGrid is a “private” message used only within HierarchyPane itself, and thus provided no pointers to other objects using the class. 3.3 Evaluating a Usage Context Once a programmer has found code that exercises a component of interest, he or she may evaluate the usage context to learn more about the reuse problem. The usage contexts we provided were embedded in coherent applications, making them “executable”; as running examples, they could be used to preview or test the component’s appearance or behavior. Alternatively, the code used to instantiate or exercise the component could be studied to extract its usage protocol. As the graphs for P2 and P4 in Figure 2 show, an important aspect of evaluating the HierarchyWindow context was an assessment of its internal complexity, prompting the programmers’ decisions to reuse the context it provided through inheritance. 3.3.1 Executing the Sample Context. The programmers working with HierarchyPane (P2 and P4) were able to preview the look and functionality of the graphical hierarchy by running the example application. They seemed to find it satisfying to see an actual instantiation of their end goal: “That’s cute. Those are very interesting” (P2 reacting to the graphical view of the org chart). Especially in the case of user interface components, it may be difficult to predict a class’ capabilities just by reading code; code comprehension also is certainly more tedious than interacting with a live application: “Oh, one thing which I don’t want to omit saying is whenever I can play with behavior of things, have no doubt, I’ll much rather play with things and watch the behavior of the stuff as opposed to looking at the code. The code is absolutely the last thing. I have trouble reading my own code, not to mention someone else’s” (P4). Note that discovering a “sender of interesting messages” is no guarantee that the usage context will be part of a self-contained application that can be initialized and executed. P2 displayed a sophisticated strategy for assessing whether and how he could instantiate the OrgChartWindow: he first checked for class methods that could be used to initialize the window, but found no guidance there. He then looked at the instance method openOn: (by convention a window method with this name establishes the connection between a window and the model data it displays); there he found a reference to the OrgChart class. He shifted to OrgChart and
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

232

?

Mary Beth Rosson and John M. Carroll

followed the same strategy there, this time discovering a class method that could indeed be used to populate a sample org chart. With this knowledge he was easily able to create an initialized org chart and open the org chart window “on” it. Interestingly, neither of the programmers working on the color-mixer project (P1 and P3) attempted to execute the context provided by the football example. They may have deemed it unnecessary, as sliders are familiar user interface components. However, it is worth noting that P1 might have benefited considerably from previewing the football sliders— he spent over 25 minutes pursuing a hypothesis that the slider functionality in HorizSliderPane is based on the scroll bars implemented in the Smalltalk Subpane hierarchy, and a preview of the slider’s visual and interactive characteristics would have quickly discounted this hypothesis. 3.3.2 Assessing Similarity to Project Context. P4 seemed to have in mind from the start that the example application could serve as a model for his reuse project, and carried out a series of interactions with it to assess its similarity to the library project. He tried a long-shot experiment, opening an instance of the generic HierarchyWindow superclass “on” his library data: “Let’s see if these two are relatives. I’m playing games, just trying to . . . .” To his (and our!) surprise, the experiment was a complete success: just 15 minutes into the problem, he was able to view his library data as a graphical hierarchy (see Figure 4(d)). The success of the experiment can be attributed to the similarity of the underlying data structures— the Library class is a subclass of the Hierarchy class, and the HierarchyWindow drawing code assumes that an instance of Hierarchy is being graphed. P4 was easily able to draw the appropriate inference: “I used it, and it worked. Using exactly the same infrastructure.” P4’s subsequent experimentation with the “borrowed” user interface to the library data was extensive (lasting about seven minutes). He recast his task as the creation of a window that worked like HierarchyWindow: “You want to issue the same thing . . . LibraryWindow new openOn whatever, to do the same, meaning, to have the same appearance of the HierarchyWindow.” He took on the goal of understanding in detail the similarities between the new interface and the ListPane interface, deciding which interactions supported by the new view might be useful in the library context. At the same time, he acknowledged the cost of working from another application’s usage context: “Naturally, whenever you provide help, you provide trouble too . . . So now I have to start this application, understand that and then understand the possible similarities or whatever.” 3.3.3 Studying Bits of Context. The code making up a usage context contains an implicit specification for how to reuse a component in a particular situation, and the programmers often studied this code to reason about their reuse problems. A common case concerned component initialization. Instantiating Smalltalk user interface components is a complex process involving the initialization of many variables (controlling characACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

233

teristics like the pane’s contents, size, responses to events, menus, etc.). Because the syntax used for initializing user interface elements is wellknown to programmers, they can look at the code from an unfamiliar usage context and extract information about which variables need initialization, what messages to use, and what to use as starting values. “We will look at AnalysisWindow and see how it sets up a slider pane. Ok, so button 1 down and button 1 move is how it’s actually controlling the slider” (P3 reading the code creating a slider in the football program). The programmers’ analysis of the code was not comprehensive—they appeared not to have the goal of developing a complete model of how the usage context worked. Rather, they focused on just the snippets of code that were relevant to the particular problem they were working on at the moment. For example, while P2 was studying OrgChartWindow’s code for initializing the contents of the HierarchyPane, he noted the presence of information concerning node selection, but explicitly postponed his analysis of that part of the usage context: “If you pick, change its values, no, let’s do that later.” The example applications were the best source of information about how to reuse the target classes, but P1 and P3 did not rely exclusively on the context contained in the football example. They seemed willing to take guidance wherever they could find it, including from the code in their own projects. Thus P1 noted that HorizSliderPane was a subclass of GraphPane, and that the color-mixer already contained an instance of GraphPane (used to display the color swatch, see Figure 1); he spent almost 40 minutes trying to determine whether this code could serve as a model for creating a slider. When P1 and P3 began developing code to process slider activity, they studied the code used to process button-presses in the original color-mixer and used it as a model for the sliders: “Well, let’s go back and look at how the buttons did it {browses redButton: method}. Buttons did it, because they had, they each had, oh . . . well, one way to do it would be to have a redSliderActive” (P1). It is interesting to speculate about why P1 and P3 chose to work from the original button processing code rather than the football program’s slider mechanism. Perhaps the relevant method (redrawGraph) seemed too far removed from what the color-mixer project needed (i.e., to update a color swatch); what would these programmers have done if the method had instead been named processSliderValues? It may also have been that because they needed to update color-mixer data (i.e., RGB values), the programmers preferred to work from a mechanism that already referred to these data. Ironically, both P1 and P3 encountered a problem in detecting which of the three sliders had received a given mouse event; this problem might have been avoided if they had studied redrawGraph, which checks all sliders whenever an event takes place. 3.3.4 Deciding to Subclass. Although the task instructions oriented the programmers toward reuse of components (i.e., by naming a specific user interface class as the object of reuse), P2 and P4 ultimately reused
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

234

?

Mary Beth Rosson and John M. Carroll

HierarchyPane by inheriting the NetworkWindow usage context. Their decisions to subclass were made after a significant amount of work attempting to incorporate the component into the original project context (28 minutes for P2, 63 minutes for P4; see Figures 4(b) and (d)). However, once the decision had been made, the remainder of the project was completed quickly. P4 finished in about 15 minutes; P2 spent about 45 minutes, but 25 of these were directed toward a complex customization goal not intended as part of the project. A key element in these decisions to reuse by inheritance was an assessment that the usage context provided by the example application was highly complex. The relevant code is distributed across several classes (NetworkWindow, HierarchyWindow and OrgChartWindow) and refers to several other unfamiliar classes (see Figure 2(b)). The comments of P4 colorfully illustrate his emerging recognition of this. The openOn: for HierarchyWindow directed him to a drawing method that is long by Smalltalk standards; it also refers to a number of other unfamiliar objects (nodes, connections, the spatial grid used in positioning them, etc.). This made reuse of this usage context seem much more difficult than he had hoped: “Ok, it won’t be that cheap, I have to compare drawGraph and getCategories,” and later, “It’s like a spider with lots of legs . . . am I really taking it whole or am I just, by pulling a branch, actually trying to pull the whole jungle?” Later, when he was working on node selection, he again encountered a complex piece of code: “Oooooh! New selection, Ok. Ah, yes, this poor LibraryWindow is like an orphan compared to this HierarchyWindow which is a very powerful hierarchy with lots of stuff.” For P4, the “turning point” seems to have been his discovery of two variables in the usage context that had no apparent analog in the library project: “Network is library, graphPane is pane, and selectedComponent was selected-something-else. But the sheer number is only three . . . library, pane and category, and I have it all. This guy has two more, lastSelectedComponent and state.” At this point, P4 briefly considered simply commenting out the code that dealt with these “unmappable” objects, but quickly decided that this wasn’t likely to work and that he should change his approach. For P2, the critical factor appeared to be his sense that a large number of internal messages were involved in node selection. In Smalltalk, all computation is carried out through message-sending, and an important category of messages are those that an object sends to itself. These are typically identified in the code via an expression of the sort self message ; such messages are often identified as “private” in a comment at the start of the method code. When P2 began studying HierarchyWindow’s node selection mechanism, he took a quick look at the code and abruptly shifted his approach: “Oh, we’re at the point where we have to decide once again whether to use the LibraryWindow here instead of where it is now. We use a bunch of stuff . . . I was halfway there, now I see what’s involved with selection. There’s a lot of internal messages that I would have to copy over that are inherited from NetworkWindow and HierarchyWindow, and we
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

235

want to copy it into LibraryWindow, and it looks like there’s going to be a lot of work ahead.” Repositioning LibraryWindow as a subclass in the NetworkWindow hierarchy can be seen as somewhat like instantiation of an application framework [Deutsch 1989]. An application framework is a group of classes designed to work together in a stereotypical way, and although NetworkWindow and its subclass HierarchyWindow were not explicitly designed to serve as such a framework, they do coordinate the activity of several other classes used in presenting and manipulating graphs. It may be that when relevant usage context is highly distributed, a key decision for programmers becomes whether to treat the context as if it were an ad hoc application framework (see the arguments of Taenzer et al. [1989] concerning the “yo-yo” problems of reuse by inheritance). Deciding to reuse through inheritance can be seen as the ultimate in reuse of uses—an entire usage context is adopted and simply specialized to meet particular project needs. Clearly this will not always be possible or appropriate. As P4’s earlier experimentation with HierarchyWindow had demonstrated, the basic models behind the library and the org chart were very similar, making it quite reasonable to reconceive of the new library system as a “kind” of HierarchyWindow. At the same time, leveraging the similarity in this way may introduce its own problems: once P4 made the decision to subclass, he took on the goal of inheriting directly as much functionality as possible. As a result, in one case he failed to specialize a method adequately, causing his library nodes to be incompletely initialized. On the surface, the enhanced project looked and worked correctly, but the underlying model was not quite correct. 3.4 Debugging a Usage Context One of the most salient characteristics of these programmers’ activity was that they moved almost immediately into code development (see Figure 4). They developed their code in an incremental fashion, working on one bit of functionality at a time, and relying heavily on Smalltalk’s interactive programming environment to guide their work. We have characterized this style of programming as “debugging into existence” [Rosson and Carroll, 1993]. This style of work was common to all four of these Smalltalk/V programmers, and appears to be common as well among expert users of other rich interactive programming environments [Lange and Moher 1989]. As described in the previous section, some attention was paid to evaluating the usage context provided by example applications. However, the programmers had no desire to analyze these example applications any more than they wished to analyze the target classes; their interest in the examples was strictly as a source of usage information. Thus much “analysis” of the usage context was interleaved with code development: a method or code fragment from the borrowed context would be used as a model for new code (often through direct copying and editing), the application would be tested, and the resulting errors would be used to identify problematic
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

236

?

Mary Beth Rosson and John M. Carroll

Fig. 5. Comparison of openOn: methods. The top two panels contrast the code for creating and initializing a red button to the code required for a red slider; the bottom panels provide an analogous contrast in the code for creating and initializing a list pane versus a graphical hierarchy. (The sample graphical hierarchy code also included code for creating and initializing a special text pane used in renaming the nodes; this code has been omitted in the interest of simplicity).

aspects of their new code, or to direct them to additional reuse information in the example application. The result was a highly contextualized, locally driven and incremental analysis of the example application that extracted just the information needed to complete the next step or two of code development. In the following we characterize this debugging-centered approach to the reuse of uses in more detail. 3.4.1 Getting an Instance Up and Running. Creating a “live” version of the target class was an important initial goal for all of the programmers—as his very first verbalization, P1 noted, “Well, I guess the first thing I would do, and I guess this sort of reflects the way I approach this stuff, is to just get one of these horizontal slider panes, and get it as a subpane.” For these projects, this meant that the first major programming task consisted of editing the original window’s openOn: method; by convention this method contains the code that instantiates and initializes a window’s interactive components. Figure 5 summarizes the code needed in the openOn: method to create and initialize a button versus a slider for the color-mixer, and a list pane versus a graphical hierarchy for the library. As the figure suggests, the creation and manipulation of Smalltalk user interface elements is complex,
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

237

with much of the relevant functionality inherited from built-in user interface classes. Getting a slider or graphical hierarchy up on the screen served as feedback to the programmers that they had successfully engaged this complex machinery and was a critical milestone in the reuse projects: “Ok, I’m happy” (P4, successful after 45 minutes of work to instantiate a HierarchyPane displaying the library data). Note that just any old instance will not suffice. A testing-centered approach to programming sets requirements for what counts as an “adequate” instance. In Smalltalk it is trivial to create new instances (all classes respond to the default instantiation message new), but it is often difficult to create an instance with any observable behavior. This is especially true for user interface components, because they must be integrated into the existing user interface framework before they can present themselves visually or receive any input. Thus early in P1’s color-mixer work, he hypothesized that HorizSliderPane was making use of standard Smalltalk scroll bars. In testing this hypothesis, he instantiated an (empty) subpane decorated with horizontal and vertical scroll bars. This result was not what he expected, but he could not discount it completely either. After more testing, he eventually discarded this hypothesis because the subpane appeared to have no meaningful behavior: “I am simply trying to get a live instance of this thing so that I can begin to poke at it and see how it behaves both in response to the user input and messages. But I’m stymied at the moment because I can’t seem to get one that behaves in what I would consider to be a sensible way with respect to user input, so I’m not willing to trust that I’ve got a good instance to explore its other behaviors.” The reuse projects in this study involved user interface classes, and by definition the creation and initialization of such objects is tied to opening a window. However, in informal observations of a colleague attempting to reuse a class implementing a specialized tree structure, we observed a similar “first get it up and running” approach—in that case, the analogous first subtask was the creation of a populated tree structure, to which test messages could then be sent in aid of making the tree fully functional. For this noninteractive component, testing involved the sending of test messages in a workspace, followed by inspection of the tree’s internal state, but the general approach of incremental extension through testing was similar to that observed here for user interface components. In an environment like Smalltalk populated with powerful interactive debugging tools, this is an entirely reasonable strategy, in that these tools are much more effective once the programmer establishes some behavior that can be explored. As P1 put it: “I mean if I can just get control, that’s normally how I want things to happen. If I get control, I can do something. If I can’t get control, I can’t do anything.” 3.4.2 Borrowing a Usage Context. In many cases, the usage context was assimilated into the project context by copying and editing borrowed code. The copy-edit style of code development has been documented before in observations of experts developing object-oriented code [Detienne 1991; ?
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

238

?

Mary Beth Rosson and John M. Carroll

Lange and Moher 1989]. As we have observed in our prior analytic work [Carroll and Rosson 1991], the Smalltalk environment facilitates this strategy by allowing multiple code browsers to be open simultaneously so that code can be conveniently copied and pasted from one code context to another. In fact, during these programming sessions, it was quite common for the programmers to have three or four code browsers open at once, such that they could browse or copy from various locations in the sample usage context while still maintaining their place in the project code. Reuse of the sample context by copying and editing reduces the amount of typing required of the programmer, and helps to insure that the details of the code (e.g., the spelling of method and variable names, the placement of line separators) are correct. In many cases, the programmers seemed to know exactly how the code needed to be edited. Early in P3’s work on the color-mixer, for example, he copied an 11-line block of code instantiating a “years of (football) experience” slider, pasting it on top of the color-mixer code instantiating the red button. He then edited the borrowed code in a straightforward, step-by-step fashion: “Ok, so use the same instance variable, redControl . . . owner self . . . I don’t know whether I really need the nonScrollbars style, but I’ll keep it and see what happens. When getContents, perform draw . . . so . . . draw method just sends the message draw to the slider to draw itself, I guess that’ll do the same thing.” Part of this apparent ease in editing can be attributed to familiarity with Smalltalk—recognizing the syntactic positioning and semantic role of instance variables, the notion that each subpane must have an “owner,” that all subpanes need a “getContents” method, and so on. Another contributing factor may have been an ability to map from one concrete situation to another, for example, recognizing that while “0” and “20” are reasonable minimum and maximum values for years of football experience, the analogous RGB values should be “0” and “255.” In other cases, the editing of borrowed code was more complex. One strategy we observed in such cases was simply to paste it in and let the environment provide editing directions. For example, P4 began developing new code in the LibraryWindow openOn: method by copying over a large block of code from the analogous method in HierarchyWindow. This code creates and initializes an instance of both HierarchyPane and another unfamiliar class, TextField. P4 noted that the code looked complicated, but chose not to analyze it at this time: “This is not only HierarchyPane; it has TextField. Ok, it’s confusing, but . . . if you are stealing, you steal first and then you see what you stole.” He then entered into a cycle of editing the code followed by attempts to save it, relying on the Smalltalk compiler to flag problems in the code. For example, the compiler directed him to edit a variable name, pane needed to be changed to graphPane: “Ok, it’s called pane . . . Ok.” After three such edit-save cycles, the updated code was successfully compiled. P2 followed a similar strategy in his editing of this same complex method, first trying to save the method, then using compiler feedback to locate problematic variable names: “Draw . . . Ok . . . graphPane, Ok.”
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

239

In another case, P2 and P4 exploited the similarity between the structure of the library project and that of the usage context, to minimize the amount of editing required. The two applications use different variables to hold the same sort of hierarchical network object (called library and network respectively): “So, network is just the network . . . that’s in org chart and in library, so that may be a good thing.” (P2). After recognizing this similarity, both programmers developed a “synonym” method named network, which simply returned the library hierarchy whenever the network object was requested in the borrowed code. Because this object was central to the drawing mechanism, this substitution simplified considerably the reuse of the borrowed context. The synonym strategy reflects a sophisticated approach to reuse of uses—it can be seen as a general approach to supplying “glue” for mapping one application context onto another. As such it might be a powerful reuse strategy to articulate and convey to less experienced programmers. Note that in this case, a simple object substitution was sufficient, but if necessary the programmers could have written code to transform the library data prior to passing it off as the network object. Of course the strategy depends on the encapsulation of internal structure typical of object-oriented languages: if network had been referenced directly in the code (rather than through access messages), this programmatic substitution would not have been possible. For the most part, the literal reuse of uses through the copying and editing of code seemed to work well; however, we did observe occasional problems associated with this style of development. P4 never pasted “on top” of the original code, but rather created elaborate comment “borders” around his original code. This allowed him to return to the original code at any point, but also often made his revised methods long and visually confusing. When changing his red button to a red slider, P3 correctly observed that he wanted to maintain the original framing ratio (defining the component’s spatial layout). He returned to the original button code to retrieve the appropriate framing ratio expression. Unfortunately, he copied the specification for the blue button, causing the red slider to be opened underneath the blue button and thus never visible. He spent almost 15 minutes diagnosing this error, despite the fact that framing ratios are a common source of error and frustration in this Smalltalk environment. P3’s belated recognition of the problem can be attributed to his assumption that his difficulties were stemming from unfamiliar aspects of the borrowed code— he spent considerable time analyzing the slider’s draw method, and experimented with arbitrary changes to the slider initialization before recognizing the familiar problem of framing ratios. 3.4.3 Analysis by Testing. A frequent source of feedback to programmers working in Smalltalk is the notification “Message not understood”— this occurs when an object is sent a message for which it has no corresponding method code (either in its own class or its superclasses). The programmers often relied on such feedback to direct them to the next piece
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

240

?

Mary Beth Rosson and John M. Carroll

of useful information in the usage context. When P1 was working to instantiate his first slider in the color-mixer, he guessed at some of the editing he needed to do (e.g., changing the slider’s title and minimum and maximum value). He also inferred that he would need a method to draw the slider. However, he waited to identify the specific method needed by first trying to open the window: “Yeah, right, draw not understood.” This feedback directed him to the usage context in AnalysisWindow, where he located and copied the sample draw: method, without even reading its code: “Ok, what do I want, draw . . . aPane draw. Sure. HorizSlider back again. Of course I didn’t actually look to see if it draws. Let’s see what happens.” A similar strategy was evident in P4’s assimilation of the HierarchyWindow context into LibraryWindow. He used “Message not understood” feedback to determine that the wrong function was being called by the menu creation code he had borrowed. After changing the code appropriately, he predicted that a similar problem was about to arise for the graph drawing method. However, after browsing that code briefly and concluding that the drawing mechanism was complex, he elected to simply try opening the window and see what happened: “Again, it’s easier just to try it.” On doing this, he received the expected “Message not understood” notification, was directed to the drawGraph: method and began the process of copying and editing the code in that method. As these examples suggest, the reuse and assimilation of the usage context into the project context was a highly iterative process. Thus when P4 had succeeded at his first major goal (getting the library hierarchy drawn), he experimented with the window and its menus to identify the next thing to work on (supporting selection of the nodes). All along the way, he relied on compiler and debugger information to identify and modify the relevant pieces of usage context. While reliance on testing allowed these programmers to minimize their analysis of the usage context provided by the example applications, the highly localized approach did introduce errors at times. For example, when P1 was working on the code to create and initialize his first slider, he copied a block of code from the football context which established a link between the slider and a piece of application data, value: (analyst data at:years). When he copied this code, P1 understood that it was setting up a starting value for the slider, but chose not to analyze what was happening in the football program at this point. Instead he replaced the argument to value: with an arbitrary integer. This shortcut allowed him to succeed at his immediate goal (getting the slider drawn), but became a problem later on, as the slider value was never initialized correctly. P1 never returned to this bit of initialization code, electing instead to “reset” the sliders immediately after opening the window. The final result was almost right, but not quite. This episode can be seen as a kind of local “satisficing.” With respect to the immediate goal of getting a slider drawn on the screen, the validity of its connection to the application data was unimportant to P1. By the time he addressed the connection between the sliders and the application, he
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming
Table I. Summary of Observations Concerning Reuse of Uses Specific Strategies Observed

?

241

Reuse Activity Finding a Usage Context Evaluating a Usage Context Executing the Context Assessing Similarity Studying Bits of Context Deciding to Subclass Debugging a Usage Context Getting an Instance Running Borrowing the Context

Find senders of messages defined for target class, focusing on “interesting” ones Look for references to application data objects in the openOn: method. Open example application “on” a basic data object from the project. Reason by analogy from familiar syntactic construction, e.g., button1Down: Look for use of unmappable instance variables or many messages to “self.” Focus first on the openOn: code for starting up a window. Use multiple browsers to work from related pieces of context. Carry out step-by-step replacement of message parameters. Edit what does not compile. Develop a method to substitute one data object for another. Adapt or develop the method identified in the notification “message not understood.”

Analysis by Testing

was out of the initialization context, and in fact had just developed code to change the sliders’ values when a color list selection was made. Thus it was more convenient for him to correct the starting values through an updating process than to return to the initialization context and analyze how to access the appropriate starting values. 3.5 Reflecting on Reuse of Uses Our observations of these expert programmers’ behavior combine to paint a picture of a well-developed set of strategies for locating and exploiting existing usage context when trying to reuse an unfamiliar class (see Table I for a summary of the behaviors discussed to this point). This extensive reuse of uses occurred despite a sense among some of the programmers that this wasn’t the “proper” way to reuse a class, that it was somehow cheating or taking the easy way out: “Yes, this is going to save a lot of time, really . . . yeah, it does feel like cheating, though, for exactly that reason” (P1). One programmer said that he would look at the example only if all else failed, but then immediately began to work from the usage context it contained. However, when probed about these feelings at the close of the experiment, the programmers indicated that the general strategy of locating and borrowing from examples is one they use frequently in prototyping Smalltalk applications: “Sometimes there are things I can borrow from and sometimes there aren’t. When there are, it’s like there are decisions about subclass, copy, lots of stuff . . .” (P2).
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

242

?

Mary Beth Rosson and John M. Carroll

Some of the reservations expressed by the programmers may have been due to a perceived demand to use more conservative methods in this experimental situation where we were documenting their programming habits. As P3 put it in his debriefing interview: “You know, you’re working with components whose interfaces you don’t completely understand, and you may break other things in the system by using them in a naive way. It seems like if you’re concerned about reliability stuff you really want to understand the interfaces you’re using as opposed to just copying and putting them somewhere.” 4. AN EXAMPLE-BASED REUSE TOOL For our general research program on example-based learning in Smalltalk, we are developing the Reuse View Matcher (RVM), a reuse documentation tool that makes explicit the usage context of an example [Carroll and Rosson 1991; Rosson et al. 1991]. We decided to create RVM documentation for the example applications (i.e., the org chart and football programs) and observe a second programming project for each programmer during which the prototype RVM was available. Our goal was to provide some preliminary observations concerning this particular form of example-based reuse documentation. In the following, we first briefly describe the RVM and the manner in which it was introduced to the programmers. We then describe our observations of the RVM in use, organizing them by the same high-level task analysis used to organize our discussion of the Smalltalk-only sessions. 4.1 The Reuse View Matcher The RVM provides a coordinated set of views of an application that uses a class of interest. Thus, the RVM in Figure 6 documents some aspects of how the org chart program reuses HierarchyPane. A programmer using the RVM can view an animation of the example application which enacts a small number of scenarios that use the class under investigation. The scenarios are selected to exemplify the typical scenarios a programmer would want to implement in reusing the class. For the org chart example, these scenarios included “displaying the organization chart,” “adding a new visitor reporting to Jack Carroll,” and “adding the new visitor name.” This brief demo is intended as an advance organizer [Ausubel 1960]—the programmer sees an instance of the class in action, and the scenarios comprising the demo then provide a structure for understanding the reuse documentation. After viewing the animation, programmers can investigate how the class was used in more detail. Each scenario can be expanded into a list of scenario-specific messages sent to the component under investigation (e.g., the messages getSelectedComponent and drawGraphReposition: are sent as part of the “adding a new visitor” scenario); these are the messages that programmers will use when developing analogous scenarios for their projects. The object map (in the upper left) depicts the relationship of the
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

243

Fig. 6. The Reuse View Matcher. In the upper right are the usage scenarios forming the basis of the reuse documentation; the lower right contains a Bittitalk Browser providing a filtered view of the class hierarchy; in the upper left is the object map; and in the lower left is the scenario commentary.

reusable component to other objects in the scenario (e.g., an OrgChartWindow is connected to a NetworkNode through the selectedComponent variable); this map is intended to help programmers plan the object connections that must be established to set up a particular scenario. When one of the scenario-specific messages is selected, a Bittitalk Browser (the group of four panes in the lower right of Figure 6) displays some of the application context associated with use of this message, i.e., the actual method code that caused this message to be sent. The Bittitalk Browser is filtered to display only classes used in the example application [Rosson et al. 1990], but is identical to a CHB in every other respect. The filtering is intended to facilitate exploration of other classes involved in the example application (e.g., the programmer can conveniently switch between the window, its subpanes, the application data and so on). The commentary in the lower left of the RVM provides an integrative summary of what is happening at any given point in the scenario, and in particular the role played by the target class. 4.1.1 Introducing the RVM. During the RVM sessions, the programmers worked on the reuse project they had not undertaken in their first
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

244

?

Mary Beth Rosson and John M. Carroll

session. The task instructions were identical to those used for the Smalltalk-only sessions, except that they were told that in this session the Reuse View Matcher was available, but that they were not required to use it in their work. As before, they were given a 20-minute introduction to a reuse problem, either the color-mixer or the library, and told the name of the class they were to reuse. After this, the experimenter gave a demonstration of the RVM that also lasted about 20 minutes. Each component of the tool was described, its design rationale provided, and its role in reuse demonstrated. A checkers game reusing the BoardGamePane class was employed as an example in this demonstration, during which the programmers were talked through several hypothetical reuse programming tasks (e.g., establishing how the window using a component refers to the application data). It is worth emphasizing at this point the difficulty of evaluating an expert’s use of a new tool in a laboratory setting. We wanted to make programmers comfortable enough with the tool that they could try it out if they chose to do so, yet we could not afford to give them the extensive experience they could gain in the real world. In a sense, however, this is also a very fair “test” of an optional tool: if an expert cannot quickly evaluate and try out a new tool, it is unlikely ever to impact established work practices [Carroll and Rosson 1987]. 4.2 Overview Three of the four programmers (P1, P2, and P4) made a concerted effort to integrate the RVM into their programming activities. The other programmer (P3) opened the RVM, watched the animation of the example application, and spent a few minutes exploring the information in the tool, but then stated that he would use his familiar CHB strategies instead: “At this point it’s not clear to me whether this View Matcher is going to offer me something that I can’t do from just looking at this org chart. I think I will probably do that.” However, regardless of how much the RVM was used, the general structure of the reuse activities in the RVM sessions was similar to that observed in the earlier sessions: the programmers relied heavily on the reuse of uses, first working from the sample context to instantiate the target component, then using the information it contained to refine the component’s appearance and behavior bit by bit. As before, they used feedback from the compiler and debugger to test and evolve their solutions incrementally. Of interest is that neither of the programmers given the library program as their second problem (P1 and P3) reused HierarchyPane by inheriting from the NetworkWindow application hierarchy. Instead both successfully assimilated the org chart usage context into the library application context. P1 added the extra instance variables referenced in the HierarchyWindow drawing and selection methods (recall that these variables were what finally drove P4 to make his library window a subclass of this hierarchy); this allowed P1 to reuse more usage context “as is,” even though he ended up including functionality irrelevant to the library project. P3 instead
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

245

carefully extracted and translated just the bits of the complex drawing and selection code that were needed for his purposes. Of course with this small number of programmers we cannot attribute this “component versus inheritance” effect to the presence of the RVM. We can only speculate that the component emphasis of the RVM documentation, combined with a rather detailed analysis of the workings of the org chart example, encouraged and supported the task of reusing HierarchyPane as a component. 4.3 Finding a Usage Context Because the RVM is based entirely on example-based documentation, the programmers had no need to “find” an appropriate usage context. However, we did observe a behavior pattern in some of the programmers which suggests that they were using the RVM to find specific pieces of usage context. Three of the programmers quickly learned to use the scenariospecific message lists (see, e.g., the upper right pane in Figure 6) as a senders “short-cut”: By finding the appropriate scenario and selecting one of these messages, they could immediately position themselves within the portion of the usage context that was relevant to their current goal, giving them access to sample code that they could browse or borrow. This strategy eliminated the need for them to remember details (i.e., specific class or method names) about the example application. 4.4 Evaluating a Usage Context All four programmers began their work by viewing the RVM animation, and this experience did seem to have the intended orienting effect: “The main benefit that this has provided me in this particular case is to show me what the pane looks like, with menu popups” (P3). In some cases, the demo may also have aided efforts to understand how the usage context worked. While working to create a red slider, P4 examined the code used to create the “years of experience” slider in the football program, and remembered from the demo what various pieces of the instantiation code might be doing: “This guy also has a label, I just call title and . . . experience, less, more, oh, very interesting . . . so it, if I remember it well, it has a title, it has a min label and a max label according to the name listed.” Unfortunately, the RVM animations also introduced new problems. The animations were structured to exemplify certain fundamental usage scenarios. They were noninteractive, because the RVM canned documentation corresponded to a particular sequence of events. However, despite our advice to simply watch the animation, P2 and P4 tried on several occasions to interact with the animations. This led to rather excruciating episodes wherein the demo process (already slow because of the reflective techniques we were using to capture the state information used to populate the object map) was slowed down further by the operating system’s efforts to process the extra mouse activity. In future work, we will need to choose between scripted demos designed to illustrate particular aspects of reuse (in which case we will include a mechanism for ignoring external input) and a
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

246

?

Mary Beth Rosson and John M. Carroll

multipurpose example which can either be “demoed” or used as a normal interactive application. As we remarked before, P3 decided soon into his session that he would rely on the standard CHB tool to analyze the org chart. Nonetheless, he did return to the RVM on occasion, but attended only to the scenario commentary (see lower left of Figure 6). This textual material describes the role of the component in a particular scenario, as well as providing an overview of how the scenario transpires. In one case, P3 used this commentary in evaluating which parts of the org chart context were relevant: “Ok, I decided I didn’t want to do that . . . [experimenter prompts for clarification] . . . I didn’t want to do what graphSelect does in NetworkWindow. In other words, all I want to do is get the name, get the node selected.” Here the overview of events taking place in the scenario seemed to help P3 distinguish between useful and irrelevant portions of the usage context. 4.5 Debugging a Usage Context In general, the most important contribution of the RVM seemed to be the structured access it provided to relevant usage context. P1, P2, and P4 used the RVM almost exclusively as a code browser for the sample usage context, regularly switching from the RVM in which they were evaluating or copying bits of usage context, to the CHB in which they were developing new project code. As in the Smalltalk-only sessions, they used testing and debugging feedback to guide their incremental code development, and used the RVM to access the bits of usage context that they needed at each step along the way. However, for one programmer the tool seemed to cause a shift in programming style. In his Smalltalk-only session, P1 had relied almost entirely on debugging information (e.g., “Message not understood”) to direct his assimilation of the usage context in the football example. In contrast, during his RVM session on the library project, he regularly used the documented usage scenarios to plan his work prior to developing and debugging his code. For example, after viewing the org chart animation, P1 did not immediately start copying and editing code from OrgChartWindow’s openOn: method. Instead, he first explored the “start up organization chart” scenario, using the documented messages and commentary to understand how the component was being initialized: “Network pane . . . oh, I see, . . . grokking, the dance that glues things together.” Over the course of the project (lasting about an hour and a half), P1 attempted five major subtasks (opening the graphical hierarchy, making nodes selectable, updating renaming, and addition and removal of book categories)—in each case, he began by exploring the relevant RVM scenario. P2 and P4 also carried out such analyses: “Let’s see; ‘starting up the analyst’ . . . we’ll need to do this, comment this out, make this a . . .” (P2, early in his work on the colormixer). However, these two programmers’ RVM interactions were much less systematic than those of P1.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

247

The scenario-based documentation appeared to map well onto these programmers’ incremental development style; they had no difficulty identifying the relevant scenario as they attempted various subtasks. It may be that documentation organized into scenario chunks of this sort encourages programmers to spend more time in analysis and planning and less in testing and debugging. 4.6 Toward an Improved RVM The design analysis underlying the RVM assumed that expert programmers’ attention would be focused on the target class [Carroll and Rosson 1991]. It also assumed that a programmer could reason about one concrete usage situation (i.e., a scenario in an example application) to develop an analysis of how to use the class in a related situation (i.e., an analogous scenario in the project under development). Our initial design underestimated the extent to which analysis and implementation activities are interleaved for programmers working in a highly interactive programming environment like Smalltalk. The RVM was geared too much toward analysis of the example application containing the usage context and not enough toward piecemeal assimilation of this context. A prime example comes in its provision of active object maps (see Figure 6): we spent considerable effort developing these maps for the sample scenarios, capturing detailed state information during the animated demonstrations and making it inspectable through the maps. However, these maps were virtually ignored; although the programmers occasionally looked at a map, they rarely if ever examined the state information accessible there. The programmers did inspect their own project objects as they progressed through the task (using Smalltalk’s inspector tool), and it may be that a reuse tool incorporating a graphical view of the programmer’s application would be of more use. The animation of the example application did help the programmers orient to the reuse task: the programmers were able to observe a running example, but spared the task of discovering how to create and initialize it. However, the scripted nature of the animation undermined programmerinitiated experimentation, which is a key aspect of a testing-centered programming style. Investigating any specific question required viewing the entire animation, and there was no facility for pursuing questions not already addressed in the script. We believe that it is important to determine whether the benefit of an animated demonstration derives largely from its being preinitialized rather than being scripted. If so, a better tool for active reuse might simply provide a preinitialized example, leaving the exercise of its functionality to the programmer. The RVM scenario analyses appeared to serve as a useful framework for evaluating and copying pieces of the usage context. However, one programmer commented that the scenario titles would have been more helpful if they had been more generic—we had deliberately made the names example-specific as an aid to analysis. We take this to be another indication that
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

248

?

Mary Beth Rosson and John M. Carroll

the programmers were interested in understanding the example only instrumentally as a means to working on their own project. Future work will consider the benefits of more generic scenario names and commentary. The RVM did encourage one programmer to devote more time to analysis prior to code development, and we will look to see whether modifying the documentation in this fashion encourages other programmers to do the same, and if so, whether such a shift improves the process or result of reuse programming. These reflections and design ideas must be qualified to some extent by the fact that our programmers only even tried to use the RVM for a couple of hours each—in the context of thousands of hours of experience with the standard Smalltalk/V environment. However, this is exactly the challenge we face as serious developers of new tools for reuse: expert programmers always have an established practice. If a new tool is to succeed, it must compete in the context of established practices. Ironically, our rather comprehensive approach to reuse analysis in the RVM may have provided too much support. The changes we envision consist to a great extent of weakening the RVM functionality to make it better suited to interleaved analysis and development. 5. DISCUSSION AND IMPLICATIONS This study must clearly be qualified in that it examined only four programmers, each working only for a few hours, it studied the reuse of a particular kind of software object (i.e., interactive components), and it examined reuse programming for only one language and environment. However, the rich behavioral protocols collected contain a variety of intriguing observations that suggest an initial characterization of reuse programming in a sophisticated interactive environment like Smalltalk. 5.1 Active Strategies for Reuse Most generally, our observations describe a process in which a class is reused indirectly, through the reuse of its “uses”— blocks of code or methods embedded in an example application. Our programmers searched for usage context, and then relied on it extensively and throughout the reuse task. The usage information provided by the example applications helped orient the programmers to the appearance and behavior of the class, provided a specification for how to evoke analogous functionality in their own project, and served as source material for a copy-edit style of code development. In some cases, the programmers elected to inherit the usage context rather than assimilating it into their project context; this appeared to be related to perceptions of high internal complexity as well as similarity between the sample and project contexts. The programmers pursued their reuse projects piecemeal and opportunistically; they used the component creation and initialization code embedded in the window startup methods to develop a runnable albeit skeletal result which they could exercise and improve incrementally, relying heavily on
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

249

interactive debugging to guide their activities at each step. We called this “debugging into existence.” To a very great extent the programmers appeared to combine analysis of the component and its usage context with the development of the code needed to reuse the component. It was quite common for the programmers to use a test of their evolving code as a directive for which piece of code to analyze or develop next. In prior work we identified a tension in the organization of user behavior that we called the “production paradox”—people want to achieve a concrete, meaningful work result as quickly as possible, but they must engage in some amount of learning or planning in order to do that (this work focused on the learning and use of office applications; see Carroll and Rosson [1987]). This tension produced distinctive behaviors: learners jumped the gun, undertaking projects they were not fully prepared for, or skipped around, using training manuals as references for self-initiated activities; experienced users learned only what they needed to carry out routine tasks, their knowledge and capability fell off sharply when exceptions or new challenges arose. We called these patterns “active use” to stress the way that the exigencies of use appeared to be limiting the scope of reflection and planning. We believe that the style of software reuse we observed in the current study reflects the same underlying tension between the felt need to achieve tangible progress and the inherent prerequisite to understand and plan. Interleaving analysis and code development, and orienting and relying heavily on concrete examples (to the point of copying code from them) can be seen as an optimization of these two conflicting motives. It is important to recognize that these active programming strategies may be caused in part by distinctive characteristics of our programmers, of Smalltalk, and of the situation we studied. We studied reuse in the context of application prototyping, which might contrast with other kinds of programming efforts, such as library development. The inherent time limit imposed by the experimental setting may have exaggerated the active strategies we observed, although the comments of the programmers after the sessions suggested that they had engaged normal programming strategies. The projects we set up were routine problems for the programmers we studied; they are familiar with building graphical interfaces, and with managing real-time events. Programmers less experienced or less confident might take a more deliberately planful, more conservative approach. The reuse tasks centered on interactive components may have encouraged the approach to “get it up on the screen and poke it.” Smalltalk itself also may encourage the fluid, opportunistic style of programming we observed. The encapsulation of state and behavior in a pure object-oriented language enables strategies that involve attending to one bit of functionality at a time; the tool-rich interpreted environment facilitates an incremental testing-intensive approach to code development. However, it is also important to note that our general findings are consistent with other empirical studies of programming and design. For example, Carroll et al. [1979] studied the early phases of the design of a
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

250

?

Mary Beth Rosson and John M. Carroll

library information system, and observed that relatively small parts of the design were developed locally until contentions forced reworking. Guindon [1990] and Visser [1990] have demonstrated pervasive opportunistic control in software design. In the domain of reuse, Lange and Moher [1989] observed that an experienced programmer extending a library of software components frequently used existing components with related functionality as templates or models for the new components. In future research, it will be important to better detail the nature of active programming and its implications. Our programmers were highly context driven and very opportunistic planners, but they all wrote some amount of new code and their work clearly followed a high-level script (first instantiating the class to be reused, then successively elaborating its appearance and interactive behavior). We need to understand the contribution of our participants, the tasks, and the Smalltalk language and environment to these patterns in reuse activity. Finally, we cannot assume that the active programming pattern is entirely (or perhaps even chiefly) a good thing: One of our programmers produced a solution that was incorrect in detail because he so opportunistically inherited as much as he could from a usage context that was very similar to his problem context. Another programmer’s assimilation of borrowed code was suboptimal, seemingly because he was focused on too narrow a goal at the time that he translated the code. Active reuse strategies may follow inevitably from the production paradox described above, and the tracking of errors attributable to the reuse of uses will be critical in better understanding and managing such strategies. 5.2 Supporting the Reuse of Uses The programmers we studied invented the strategies we observed or learned them from colleagues. As we noted, they occasionally expressed some embarrassment at their own reluctance to fully analyze code they wanted to reuse and their predilection for “stealing” usage protocol. If these practices survive—indeed emerge from—the natural selection pressures of professional programming, we should at least consider that perhaps they should be the topic of instruction in (Smalltalk) programming and the object of deliberate support in the design of documentation and tools for programmers. Our study has several implications for how reusability in object-oriented programming should be conceptualized, taught and supported. Most generally, it suggests the desirability of a broader view of component reuse: the pluggable “software IC” metaphor [Cox 1987] is not the only way reuse has been conceptualized (for example, as we discussed above, Deutsch [1989] and Meyer [1987] advocate the reuse of designs or application frameworks via specialization of abstract classes), but it is a dominant image in talking and thinking about reuse. The classes we developed for reuse (the slider and the graphical hierarchy) could be recruited as pluggable components; the slider, in particular, is an interface widget and eminently pluggable.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

251

However, all of the programming projects described here reused these classes through assimilation of some or all of the usage context embedded in the example applications. This suggests the appropriateness of a more situational view of reuse in which pluggable, context-free reuse is the simple and ideal case. This implication for instruction entrains a related implication for the documentation of software components. Our four programmers were able to find example uses of the classes they were to reuse, but in many situations this would not be true, and hence an example-oriented reuse strategy would be thwarted. Thus, at the highest level, our findings underscore the importance of developing good examples as part of documenting reusable components. This point, in turn, raises issues about the characteristics of “good” examples for reuse. “Active” programmers are not inclined to undertake thorough and general analyses of usage examples. Our study suggests that they may often wish to understand both the class they are reusing and a usage context for the class only as much as necessary to take the immediate next step in planning and code development. An implication of this is that the example applications should be as simple and generic as possible. This raises several research questions: Is it more important for a usage context to be simple and generic than to be “interesting”? We tried to make the football program interesting in its own right—thinking that this would help to motivate the analysis needed to use it as a model— but wonder now whether its distinctiveness might have been more an obstacle than a motivator. If a reusable component has a rich set of behaviors, should its usage be illustrated via several simple examples rather than one comprehensive but more complex example? Simple examples require less analysis, but at the risk of not addressing dependencies among different usage scenarios. Finally, based on the contrast we observed between the reuse of HierarchyPane as a component versus its reuse through inheritance from the NetworkWindow hierarchy, one can ask whether different types of usage context are appropriate in supporting reuse by inheritance versus components. Generic examples may be more likely to overlap with a project’s own context and thus encourage an inheritance-based approach; perhaps examples intended to support component-based reuse should be more specific than those documenting the subclassing approach. Our observations of the RVM in use have implications for example-based reuse tools. At a high level, the programmers’ reactions suggest that such tools could do more with less: A runnable example is useful, but detailed information concerning its internal state changes is not. Decomposing the usage context into application scenarios seemed to help programmers find relevant bits of usage context, but the application-specificity of the scenarios may have been a distraction. Given our general observations concerning the interleaving of analysis and implementation, a more effective reuse tool might be one that explicitly coordinates these two programming activities— perhaps by using a single set of scenarios to organize both the analysis of the usage context and the development of analogous project code.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

252

?

Mary Beth Rosson and John M. Carroll

From the perspective of reuse practice, a key issue will be the source of usage context. Within our research setting, we had the luxury of building and refining our example applications to make them as useful as possible. In our study of the RVM, we had the time and motivation to document the usage scenarios implicit in the examples. But who will develop and document such sample usage contexts in conventional software development settings? Likely candidates are the developers and vendors of commercial class libraries. The construction of test scenarios is common in software development; our observations suggest that even if such scenarios were piecemeal and disconnected, programmers would be eager to use them as models in their own work. To the extent that such scenarios can be refined and documented, they might support a more analytic approach to the reuse of uses, perhaps minimizing the risks of relying too much on the sample context.
ACKNOWLEDGMENTS

We are grateful to several anonymous reviewers for comments on an earlier version of the article.
REFERENCES AUSUBEL, D. P. 1960. The use of advance organizers in the learning and retention of meaningful verbal material. J. Educ. Psychol. 51, 267–272. BELLAMY, R. K. E. AND CARROLL, J. M. 1990. Redesign by design. In Proceedings of Human-Computer Interaction: Interact ’90 (Cambridge, U.K., Aug. 27–31). North-Holland, Amsterdam, 199 –205. BIGGERSTAFF, T. J. AND PERLIS, A. J. 1989. Software Reusability: Concepts and Models. ACM, New York, New York. BIGGERSTAFF, T. J. AND RICHTER, C. 1987. Reusability framework, assessment, and directions. IEEE Softw. 4, 2 (Mar.), 41– 49. CARROLL, J. M. AND ROSSON, M. B. 1987. The paradox of the active user. In Interfacing Thought: Cognitive Aspects of Human-Computer Interaction. MIT Press, Cambridge, Mass., 80 –111. CARROLL, J. M. AND ROSSON, M. B. 1991. Deliberated evolution: Stalking the View Matcher in design space. Hum. Comput. Interact. 6, 3– 4, 281–318. CARROLL, J. M., KELLOGG, W. A., AND ROSSON, M. B. 1991. The task-artifact cycle. In Designing Interaction: Psychology at the Human-Computer Interface. Cambridge University Press, New York, 74 –102. CARROLL, J. M., SINGER, J. A., BELLAMY, R. K. E., AND ALPERT, S. R. 1990. A View Matcher for learning Smalltalk. In Proceedings of Human Factors in Computing Systems (CHI ’90). ACM, New York, 431– 438. CARROLL, J. M., THOMAS, J. C., AND MALHOTRA, A. 1979. A clinical-experimental analysis of design problem solving. Des. Stud. 1, 2, 84 –92. COX, B. J. 1986. Object Oriented Programming: An Evolutionary Approach. Addison-Wesley, Reading, Mass. COX, B. J. 1987. Building malleable systems from software “chips.” Computerworld (Mar.), 59 – 86. DETIENNE, F. 1991. Reasoning from a schema and from an analog in software code reuse. In ? Proceedings of Workshop on Empirical Studies of Programmers (ESP IV). Ablex, Norwood, N.J., 5–22. DEUTSCH, L. P. 1989. Design reuse and frameworks in the Smalltalk-80 system. In Software Reusability. Addison-Wesley, Reading, Mass., 57–72.
ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.

The Reuse of Uses in Smalltalk Programming

?

253

DIGITALK, I. 1989. Smalltalk/V PM: Object-Oriented Programming System. Digitalk Inc., Los Angeles, Calif. ERICSSON, K. A. AND SIMON, H. A. 1980. Verbal reports as data. Psychol. Rev. 87, 215–251. FISCHER, G. 1987. Cognitive view of reuse and redesign. IEEE Softw. 4, 3, 60 –72. FLANAGAN, J. C. 1954. The critical incident technique. Psychol. Bull. 51, 28, 28 –35. GUINDON, R. 1990. Designing the design process: Exploiting opportunistic thoughts. Hum. Comput. Interact. 5, 1, 305–344. HELM, R. AND MAAREK, Y. S. 1991. Integrating information retrieval and domain specific approaches for browsing and retrieval in object-oriented class libraries. In Proceedings of Object-Oriented Programming, Systems and Applications. ACM, New York, 47– 61. JOHNSON, R. E. AND FOOTE, B. 1988. Designing reusable classes. J. Object-Oriented Program. 1, 2 (June/July), 22–35. LANGE, B. M. AND MOHER, T. G. 1989. Some strategies of reuse in an object-oriented programming environment. In Proceedings of Human Factors in Computing Systems, CHI ’89 Conference. ACM, New York, 69 –74. LEWIS, J. A., HENRY, S. M., KAFURA, D. G., AND SCHULMAN, R. S. 1991. An empirical study of the object-oriented paradigm and software reuse. In Proceedings of Object-Oriented Programming, Systems and Applications. ACM, New York, 184 –196. LINTON, M. A., VLISSIDES, J. M., AND CALDER, P. R. 1989. Composing user interfaces with InterViews. Computer 22, 2, 8 –22. MEYER, B. 1987. Reusability: The case for object-oriented design. IEEE Softw. 4, 2 (Mar.), 50 – 64. MEYER, B. 1988. Object-Oriented Software Construction. Prentice-Hall, New York. PRIETO-D?AZ, R. 1991. Implementing a faceted classification for software reuse. Commun. ? ACM 34, 5 (May), 88 –97. RAJ, R. K. AND LEVY, H. M. 1989. A compositional model of software reuse. In Proceedings of European Conference on Object-Oriented Programming (ECOOP ’89). British Computer Society, London, U.K., 3–24. REDMILES, D. F. 1993. Reducing the variability of programmers’ performance through explained examples. In Proceedings of Conference on Human Factors in Computing Systems: INTERCHI ’93. ACM, New York, 67–73. ROSSON, M. B. AND CARROLL, J. M. 1993. Active programming strategies in reuse. In Proceedings of ECOOP ’93—Object-Oriented Programming. Springer-Verlag, Berlin, 4 –18. ROSSON, M. B., CARROLL, J. M., AND BELLAMY, R. K. E. 1990. Smalltalk scaffolding: A case study in minimalist instruction. In Proceedings of Human Factors in Computing Systems, CHI ’90 Conference. ACM, New York, 423– 429. ROSSON, M. B., CARROLL, J. M., AND SWEENEY, C. 1991. A View Matcher for reusing Smalltalk classes. In Proceedings of Human Factors in Computing Systems (CHI ’91). ACM, New York, 277–284. SINGLEY, M. K. AND CARROLL, J. M. 1990. Minimalist planning tools in an instructional system for Smalltalk. In Proceedings of INTERACT ’90. North-Holland, Amsterdam, 932– 944. TAENZER, D., GANTI, M., AND PODAR, S. 1989. Problems in object-oriented software reuse. In Proceedings of European Conference on Object-Oriented Programming (ECOOP ’89). British Computer Society, Cambridge, U.K., 25–38. VISSER, W. 1990. More or less following a plan during design: Opportunistic deviations in specification. Int. J. Man Mach. Stud. 33, 3, 247–278. Received June 1994; accepted October 1995

ACM Transactions on Computer-Human Interaction, Vol. 3, No. 3, September 1996.


推荐相关:

事业单位人员招考(聘)考务管理系统英文中文译文

TCL, and SmallTalk are often used for ... By object data encapsulation, enhances reuse rate... 19.General programming:Any class of type all ...


delphi is a new visual programming environment

using a flexible reusable integrity of the object-oriented programming ... smalltalk, and so on, although with the object-oriented features, but ...


Design Patterns

use of patterns is essentially the reuse of well...mainstream objectoriented programming languages .......implement the pattern in C++ or Smalltalk (or ...


Introduction to Java

TCL, and SmallTalk are often used for ... By object data encapsulation, enhances reuse rate...In the multi-threaded programming environment, it ...


java介绍外文翻译

TCL, and SmallTalk are often used for ... By object data encapsulation, enhances reuse rate...All the high-level programming For example, Java...


Design Patterns 设计模式

member variable in C++ and self in Smalltalk. ...When you use a framework, you reuse the main ...(programming, languages) An entity that can be ...

网站首页 | 网站地图
All rights reserved Powered by 学霸学习网 www.tceic.com
copyright ©right 2010-2021。
文档资料库内容来自网络,如有侵犯请联系客服。zhit325@126.com