a view matcher for reusing smalltalk classes - CiteSeerX

A VIEW MATCHER FOR REUSING SMALLTALK CLASSES Mary

Beth Rosson and John M. Carroll

IBM

T.J.

Watson Research Center P.O.Box 704 Yorktown Heights, NY 10598 914-784-7738, [email protected], [email protected]

Christine

Sweeney

Department of Computer Science University of Washington Seattle, WA 98195 ABSTRACT A prime attraction of object-oriented programming lan~ages M the posslbdit~ of reusing code, We examme the support provided by Smalltalk to pro~ammers attemptin to incorporate an existing class mto a new. design, .f ocussing on issues of usage examples, object-spec~lc analysis, how-to-use-it information, and ob”ect connections. We then describe a View Matcher i“or reuse, a tool that documents reusable classes through a set of coordinated views onto concrete usage examples; in three scenarios, we illustrate how the tool addresses the issues raised in our analysis of reuse in Smalltallc. KEYWORDS: progr amming

object-oriented programming, tools, documentation

REUSE IN SMALLTALK

reuse,

The Smalltak environment is populated with a number of interactive tools that programmers may employ in finding and reusing existing classes (a class is an object deftition). Premier among these is the which or antzes existing class hierarchy browser, classes vis-a-vis shared behavior. Co f e reuse typically involves searching this hierarchy and trying to understand the behavior of classes.

INTRODUCTION Various features of object-orien~ed programming (OOP) are seen as potential facfitating code reuse: the modularity that results 1’rom encapsulating data and rocedures, the abstraction provided by object inte J ace?, the behavior-sharing supported by mechanisms hke inheritance 13], The 00P reuse allure has induced many deve i opers to try 00P environments and has catalyzed research on the design and use of reusable object types [9,11].

Usage examples Programmers learn effectively from good examples [14], and Smalhalk programmers often try to understand how to use a software component by examining examples of its use. It is sometunes easy to do this by creating an instance of a target class, and sending it messages to see what happens. Another option is to examme existing applications that make use of a class; Smalltalk system tools exem My usage of various classes in the hierarchy, Bot { approaches have limits: It is not easy to create typical or revealing exam@es of objects not yet understood; many objects exlubit interesting behaviors only workin in concert with other objects [8]. The system too ?s are interesting, but they are neither simple #nor paradigmatic; extracting reuse lessons from them 1s complex.

The term “reuse” can refer to dktinct strategies for taking advantage of existing code. One is reuse via inheritance; new types of objects are specialized from existing types. Another is reuse via templates [12]; ieces of existing objects are copied and edited to But the most pervasive is reuse E uild new objects. via components; instances of existing ob”ect types become parts of new objects [4,15]. Sm A talk n a pure case of this: because everything in Smalltalk is an object, even the simplest code expressions require the reuse of extstmg object types (e.g., characters, numbers, booleans). Permission grantad direot

to

copy

provided commercial

title

of the

that

copying

that

and/or

specific

01991

ACM

fee

tha copies

advantage,

publication

Machinary.

without

and

tha ACM its date

is by permission To copy

all or part

otherwise,

of

ara not made

this

copyright

appear,

material

or distributed

and

of the Association

notice notice

is

a fea

permieeion. 0-89791

-383 -31911000410277

analysis

If a usage example can be found, Smalltalk offers various tools for analyzing the role played by an object. A programmer wondering how to use a can use the interactive ListPane, for example,

and tha is given

raquiree

Object-specific

for

for Computing

or to republish,

In order to reuse existing components, a programmer must ffist discover relevant components and assess their usefulness to the reject at hand. Once a component has been ident” $ led, the programmer must determine how it fits into the project: how to create it, how to connect it to other components, how to extract behavior from it. While a number of researchers have be n to address the component search problem [7, 15], title attention has been paid to the problem of determining whether and how to use a candidate component once located. Our View Matcher for reuse was designed to support these aspects of component reuse.

. ..$1 .50

277

on Smalltalk learning 3]: simultaneous coordinated views onto an examp f e. However, in this case the nature of the examples, the content of the views, and their coordination 1s a function of reuse rather than A key assumption is that rolearning concerns. grammers wishing to reuse corn~~nents atready { ave : they are in the a .well-defmed ~rogrammin rmdst of building an app i “cation and are asking themselves whether and how a target class might be useful. Thus the orientation of the View Matcher for reuse is one of task-oriented documentation: we attem t to provide just the information a programmer nee.! s to ~corporate a component into an ongoing design project.

debugger to track the messages sent to the ListPane containing the class list in the class hierarchy browser; changes in the internal state of the pane can also be analyzed via the inspector. However, management and coordination of the information in these tools is left entireJy u to the programmer: the progmmmer must decide f ow and when to “break” the application, must identify the relevant (ListPane) object, and must extract and or anize the activity of that object from the backgroun i of other message-passing activit y.

How-to-use-it

information

The Smalltalk environment encourages a how-itworks orientation for programmers trying to understand a target class. When a class is selected in the browser, the rogrammer’s attention is directed to information a t out its implementation (the variables defined for it, the messages it can respond to and their listings). This is an appro@ate orientation for proammers attempting to bw.ld or modify a class, But Por programmers wishin simply to reuse a class, information about how tfl e class works may not be Indeed, it may be best not to provide this necessary. information, lest programmers et distracted or confused by implementation det 2 “ s, or be tempted to make changes that are not necessary [4].

Figure 1 shows a View Matcher opened by a programmer considering reuse of the Network class. The vignette pane in the upper right lists several example applications (a system communications map, a resource allocation tracker, a graph editor) that use this class. The progmmmer has double-clicked on the graph editor vignette; this initiates a brief animated demonstration of the editor, and expands the vignette into its “e isode” list, decomposing it into episodes in which t{ e Network participates. If the programmer double-clicks on one of these episodes, it expands in turn, listing all messages sent to the Network during that episode. Thus the vignette pane provides an object-specific analysis of an application’s message activity, Ming just the messages relevant to a target object’s use in example episodes.

The Smalltalk browser provides a “senders” function a programmer that operates on message names: wantin to reuse a class can ask for a list of all other metho J s (message implementations) that send a parHowevert the Smalltalk language is ticular message. built on polymorphism (dtierent objects respond in different ways to a same-named message) and dynamic binding (the object receiving a ~ven message is not determined untd runtime). These characteristics make it impossible to ascertain which senders of a messag~ are actually us,ing this message to communicate with the target object (+though with experience pro~ammers develop heumtlcs for recogmzmg the most hkely candidates).

T+he object communication ma in the upper left deplcts the ~onnectlons among t f e objects participating Each node in the graph rem the editor vignette. resents an instantiated object; the directed links are abeled with instance variable names, indicating how the various objects are connected (e.g., the Network object is held in the network instance variable of the GraphEditor object). The internal state of these objects can be inspected; the state of an inspected object M tied to the currently-selected episode (the relevant information about the instances 1s copied and saved at predefmed points during the animated demo).

r

Object connections

In the lower right is a class hierarchy browse~ this is a Bittitalk Browser [16], giving access to only the classes and methods used in the vignette under analysis. Programmers can explore any of the vi~ette’s classes and methods opportunistically. Selectm one of the messages sent to the Network m an episo i e (in the vi~ette analysn), updates the browser to display the or@n (class and method) of the message (see the GameBoardPane example in Figure 3).

An important aspect of reusing a component is understanding how to connect it to other objects in This information can be dfllcult to obtain a design. through the class hierarchy browser: the connections are realized as instance variables, and although a roammer can easily see the instance variables de t?med f or a given class, tracking down where and how they are assigned or changed can involve substantial mental simulation across a number of individual methods, often including forays into other related classes. A more concrete strategy is to open a debugger on an a plication that uses a class of interest. By examining t 1!e stacked messages at different points m time, the programmer can determine which objects are sending messages to a target object, However, it is up to the programmer to generalize across such message stacks, to induce a (hopefully) stable model of communication and control relationships among what is often a large set of cooperating objects.

Finally, the commentary pane in the lower left characterizes the usage of the target at different “levels”: when a vignette is frost selected, the commentary summarizes the target ob”ect’s contribution to the a plication as a whole. W 11en an e isode is selected, t f e object’s role in that episode is f escribed, and if a specKlc message within an episode is selected, the consequence (for the ap@ication) of sending that particular message is described. To illustrate the components of the View Matcher and how they address reuse concerns, we present three ~rogrammer scenarios. The fwst deals with deterrnuung wl@her a parti@ir class is approp~ate, the second with understanding how to fit a class tnto

THE VIEW MATCHER DESIGN The View Matcher for reuse is a second instantiation of the View Matcher genre developed in earlier work 278

Figure

1.

The vignette pane is in the upper right, the communication map in A View Matcher for the Network class the upper letl, the class hierarchy browser the lower right, and the commentary the lower leh. (In the actual system, these components are distinguished by color.)

279

an existing design, particular behavior

and the third with from a class.

Can I use a Network

to maintain

obtaining

subclass of browser that this class is a ApplicationWindow. Similarly, the programmer discovers that the AnalysisWindow has an instance varholdin instamce of iable dataPane ContinuHistogramPane, a subclass of Gr$hPane. ing the analysls, the programmer sees an instance variable (s1 i.derCollect ion) of the HistogramPane that holds an OrderedCollection; the at: I connection from this collection indicates that the object has indexed (not named) instance variables, and that the fust of these indexed instance variables holds a Slider. Finally, the programmer sees that the slider’s mode L variable points to the FootballAnalyst.

some

my design notes?

A programmer has just begun to work on a system for documenting design argumentation: the system is to represent and manage several lands of entities (issues, positions, arguments, etc.) and links among entities (suggests, supports, specializes, etc.). These requirements suggest a Network class, and the pro~ammer opens a View Matcher on that class to see ti it might be ap ro riate. Double-clicking on the fwst vignette in t [[ e “st, “a system communications map”, the programmer views a short demonstration of a communication network; different processor types (e.g., personal workstations, fde servers, mainframes are added and removed, and are connected via J ifferent kinds of links (e.g., LAN, co-ax). The commentary associated with the vignette describes the networks management of nodes and links.

Reasoning by analogy, the pro ammer concludes that the ColorMix class currently f eing developed will pla the role of the football analyst; the red, blue and ye 1 ow input sliders will each point to a ColorMix The rogrammer asobject via their mode I variable. sumes that the FootballAnalyst cI’ass has some functionality for responding to value changes sent by the sliders, and makes a mental note to fmd and replicate that functionality in the new ColorMlx class.

The prograrmner concludes that the Network class will indeed be useful in the design notes project. Before moving on, however, the programmer explores the second vignette, “a resource allocation tracker”. This demonstration portrays a set of processes competing for a set of resources; cycles in the graph two or more processes in deadlock because of mutu h resource dependencies) are automatically detected and highlighted. Clearly, a design notes network may also contain cyclical connections. This leads to a new idea: the tool ~an flag ~ycles (possible circular arguments) for special attention.

Looking at the other objects in the map, the rogrammer also realizes that the HistogramPane w’ll be useful to the color application, and decides that the three color adjustment sliders will be contained by an instance of that class. Remembering the football demonstration, however, the programmer recognizes that the AnalysisWindow object should be replaced by a ColorMixWindow,. a new subclass of ApplicationWindow that wdl have one pane for color input, and a second for the mixed output.

This scenario ilh+strat~s how the View Matcher documents the functlonaht y of target classes through examples. The programmer can understand use in a situation, rather than examinin g the messages defined for a class, and either guessing functionality from message names, or anal zing the method code. The scenano also illus$-a~es i ow ,the use of ~xamples can sup ort opportumstlc planning: analofgcal reasoning evo [ ed by concrete examples may engender new insights about the problem at hand [10].

How do I connect

sliders

This scenario illustrates the contributions of the View Matcher to the early stages of a design, when a proammer is wondering about which objects to use and f ow to connect them. By analyzin the network of objects makin up the football ap f “cation, the programmer is ab f e to ma out the re !?ationslups among the develo ing set of o! jects in the color application. come in the discove~ of Addition a? contributions smother class (Histo arnPane) that might be of use, and the realization tr lat the application will need its own window class to play the role of the AnalysisWindow in the footbalt example. In this sense, the View Matcher goes beyond documentation of individual reusable classe~, giving programmers a view of paradi~atic orgamzations of cooperating objects (or application frameworks [5]).

to my color-mixer?

A programmer has come upon the Slider class in the class hierarchy, and after viewing some vignettes, has concluded that it will provide just the user interface capability needed for a color-mixing tool being designed: sliders convert mouse movement into data of the consevalues, with continuous updatin quences. How should the three st “ders (red, green, ~d blue) be hooked up to the color-mixing application?

How do I get GameBoardPane?

the

selected

square

from

A programmer building a chess game has found a useful class, GameBoardPane: the pane creates and displays an appropriately scaled board display, and it converts subsequent mouse clicks on the board into square selections. The programmer has already connected a GameBoardPane object to the current chess game, and has successfully displayed an 8x8 board.

The programmer opens a Reuse View Matcher on the Slider class, and double-clicks on the f~st vignette, “a In this demonstration, sliders confootball analyst”. trol player attributes (e.g., speed, experience) that predict player success measures (e.g., tackles, interceptions).

The chess ame must now be programmed to extract the user-se i?’ ected squares from the GameBoardPane. In Figure 3, the programmer has double-clicked on the “selecting a square” episode in the Gomoku vignette. The episode has expanded into messages that either were sent to the GameBoardPane, or that included the pane as an argument. The communi-

The rogrammer exapines the object communication map f or the football vignette see Figure 2), observing that it includes an instance o [ FootballAnalyst which has an instance variable window holding an instance of i%xalysisWindo w. The programmer selects the window object, confirming via the class hierarchy

280

,a+apy

\

sIiderCollection

model =&E!z!D

Figure

2.

/

A communication

map for the football

class:

links

the labeled

deDict instance

analyst tignette: Each node variable connections.

map displays the object connections pertaining cation to the e isode, and the commentary describes the role played { y the GameBoardPane.

method,

the

programmer

edits

the

represents

By using the View Matcher, scenario is able to determine

an instance

of a

the programmer in this what message or mes-

sages to send to the target object, as well as the apphcation context in which to do tlus. An tmportant characteristic of the scenario is that all the reasoning is done from the perspective of wing the target class; has no need (and is not encouraged) the programmer

The programmer has already defined a new kind of window for the chess application (ChessWindow) that displays the game board along with information about each player’s remaining pieces. Like Gomoku’s variable BoardGameWtndow, it has a boardpane that refers to the GameBoardPane. With this in mind, the programmer selects the second message in z= boardpane the square selection episode, square The browser updates to show selectedSquare. that in the Gomoku game, this message is sent in the BoardGameWindow select: method. The commentary explains that the GameBoardPane sends the select: mesqa e t? its wind~w when a mouse-up event occurs wit &n Its boundanes. Knowing that the event-handling for a pane is defined in its window’s open

in the graph

accomplishes to examine how the GameBoardPane Further, because the the square-selection task. square-selection protocol is illustrated with actual code, the programmer is able to employ the copy-edit strategy for creating the analogous code in the chess application. Our concern has been sup ortin reuse without requiring how-it-works know f% edge, ut we note that the View Matcher can su port how-it-works scenarios. For example, a user o F Network mi t wonder how nodes are stored. Inspecting the $ etwork in the communication map before and after adding a node could answer this question.

open

method in the ChessWindow class, adding the event to the GameBoardPane charactermouse-u copies the select: istics. & en the programmer method from the BoardGameWindow class to the ChessWindow class, and begins editin it to draw the currently selected game piece in the sef ected square.

GENRE AND CUMULATION The View Matcher for reuse is not simply a design response to problems of code reuse. It 1s art of an ro ect studying the evolution o f tools to ongoing support t Ele earning and use of Smalltalk [2]. This

281

Figure

3.

A View Matcher for the GameBoardPane class: The “selecting a square” episode has been expanded in the vignette pane, revealing messages sent in the episode that involve the instance of Game Board Pane. The commumcation map, class hierarchy and commentary provide information about the currently-selected mes saee .r–– .-– . in thk e~isode.

282

project is a case study of the task-artifact framework [1]; the framework involves the analysis of the psychological claims associated with artifacts in use, with subse uentreasoning about neworim roved artifacts guide 1 b these analyses. Within this Yrarnework, the design o { the View Matcher for reuse has been driven by several artifact analyses: claims associated with learning scenarios for Smalltalk and an earlier View Matcher [3], as well as claims associated with Smalltalk in code reuse situations, The View Matcher for reuse is implemented in the Smalltalk/V PM environment [6, 17]. We have developed documentation in four application arenas (the network, slider and board game examples described here, as well as an application for resouce allocation in a multiprocessing environment): and are beginning to gather behavioral data concernm its effestiveness in reuse situations. At this point, ai of the documentation for a target class is developed by hand — the class documenter creates one or more usage applications, and develops the episode-based analyses underlying the usage documentation. We have begun to design an editin tool (with a structure isomorphic to the View Mate % er presentation) to assist in the preparation of these documentation components.

2.

Carroll, J.M, & Rosson, M.B. (1991). Deliberated evolution: Stalking the View Matcher in design space. Provisionally accepted for publication in Human-Computer Interaction

3.

Carroll, J. M., Singer, J,A., Bellamy, R, K, E., & A View Matcher for learnAlpert, S,R, ~) 1990. ing Smallt hi CH~90 Proceedings (PP.431-438), New York: ACM.

4.

Cox, B.J. (1986). An evolutional Addison-Wesley.

5.

Deutsch, L.P. (1989). Design reuse and framethe Smalltalk-80 system, In works in T.J.Biggerst$o~m$J. Pe#s (Eds.), Sof~are t-eApplications and usability. Experience. New York: ACM.

6.

Digitalk, Angeles:

7.

Gangopadhyay,D. & Helm, A.R. (1989). A model-driven approach for the reuse of classes from domain spec~c object-oriented class re ositories. IBM Research Re ort RC1451O, BM T.J.Watson Research, Yor i town Heights, NY, 10598.

Inc. (1989). Digitalk, Inc.

Smalltalk/

V PM.

Los

f

We have also begun to consider ways to automate the generation of the View Matcher reuse documentation: It is possible that once an example application is developed, the documenter could “act out” the usa e episodes, and the relevant object maps and episo 8 e analyses could be extracted from these transactions. However, our behavioral evaluation of the View Matcher for reuse is likely to suggest enhancements or even major modifications to the reuse documentation and representation techniques used by the tool. We will pursue issues of automating the documentation process on$ after we have established the usefulness and usabdity of the current system.

8.

Gold, E. & Rosson, M.B. (1990). Objectcentered environments for Smalltalk. IBM Research Report RC 15548, IBM T.J. Watson Research, Yorktown Heights, NY, 10598,

9.

Fischer, G. (1987). Cognitive view of reuse and redesign, IEEE Sof~are (July), 60-72.

10.

Holland, J. H., Holyoak, Thagard, P.R. (1986), inference, [earning and Mass.: MIT Press.

11. Johnson, R.E. & Foote, reusable classes. Journal gramming I(2), 22-35.

As we evaluate and use the View Matcher for reuse, our attention will focus on issues articulated through the series of analyses that have ~haped it, — the psychological consequences of the mforrnatlon filtering tedllniques it employs. Our experiand coordination ence with this View Matcher will enrich our underand design; this standing of Smalltalk progr amming in turn will support the continued development of the View Matcher genre.

This work was done while Christine Sweeney was a student intern in the User Interface Institute at the IBM T.J.Watson Research Center. We thank Sherman Alpert and ,three anonymous reviewers for comments on an earlter version of the paper.

13.

Meyer, B. (1988). Object-oriented softiare struction. New York: Prentice Hall.

14.

Pirolli, P.L. & Anderson, J.R. (1985). The role of learning from examples in the acquisition of recursive rogramming skills. Canadian Journal of Psycho rogy, 39, 240-272.

15.

Raj, R.K. & Levy, H.M. (1989). A compositional model of software reuse, In Proce:#tz~g of ECOOP’89 (pp. 3-24), London: Computer Society.

16,

Rosson, M, B., Carroll, ~9~.;tmal#~dkcma~lding: CHI’90

17.

283

B, (1988). Designing of Object-orieted Pro-

Lange, B.M. & Moher, T.G. (1989). Some strategies for reuse in an object-oriented proIn Proceedings CHI’89 ETarnming environment. (PP. 69-74), New York: ACM.

REFERENCES Carroll, J. M., Kellogg, W.A. & Rosson, M.B. The task-artifact cycle. In (forthcoming). J. M. Carroll (Ed.), Designing interaction: Psythe human- compu~er interface. chology at Cambridge, U. K.: Cambridge University Press.

K.J., Nisbett, R.E. & Induction: Processes of Cambridge, discovery.

12.

NOTES

1.

Object oriented programming: Reading, Mass.: approach.

(pp. 423-430),

con-

J, M., & Bellamy, R,K.E, A case study of In Proceedings of New York: ACM.

Rosson, M. B., Carroll, J. M., & Sweeney, C. (1991). Demonstrating a View Matcher for reTo appear in Prousin Smalltalk classes. cee c?ings of CHI’91, New York: ACM.