a view matcher for learning smalltalk - CiteSeerX

April 1990

CHI 90 I’tweedngs

A VIEW MATCHER FOR LEARNING SMALLTALK John M. Carroll, Janice A. Singer, Rachel K.E. Bellamy, and Sherman R. Alpert

User Interface Institute IBM T.3. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 ABSTRACT

The View Matcher is a structured browser for Smalltalk/V. It presents a set of integrated and dynamic views of a running application, intended to coordinate and rationalize a programmer’s early understanding of Smalltalk and its environment. We describe the system through two user scenarios involving exploration of the model-view-controller paradigm. KEYWORDS: education, discovery learning, object oriented programming, software environments

Object-oriented programming (OOP) technology has redefmed programming and the psychological implications of programmin g activity in a variety of ways. In this paradigm, programs are communicating objects, and progr amming is using and/or specializing existent objects and their methods. Identifying the right computational objects and their message protocols is the major programming task. Traditionally important programmin g tasks, like designing control flow, are commensurately supplanted. The development of OOP was explicitly motivated by psychological rationales; thinking in terms of communicating objects is supposed to be natural, more natural than designing by functional decomposition [7, 121. It is becoming recognized that there is a distinctive cognitive psychology of object-oriented programming and design [13], but it is clear that this includes distinctive learning challenges [9, 10, 143. For example, OOP entails substantial interactive search and management in vast code libraries, like Smalltalk’s Class Hierarchy, to achieve even simple results. This can be a formidable obstacle.

Pemrission to copy without fee all or part of thii material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish requires a fee and/or specific pemkssion.

0 1990 ACM 0-89791~345-O/90/0004-0431

1.50

We have become interested in how programmers get started with Smalltalk programming. Our approach has been to deveIop a series of tools to support learning by means of working with concrete examples; we have previously applied this approach to designing instruction for interactive end-user office applications [4, S]. In this paper, we describe one of these tools, the View Matcher. THE VIEW MATCHER

The View Matcher is a structured browser for Smalltalk/V [SJ. It presents multiple views of an up plication, in contrast to a strictly logical decomposition of programming objects as in the Smalltalk Class I lierarchy Browser. We provided a recipe database and the games tic-tat-toe, blackjack, and gomoku as sample applications. The user can interact with these applications and at the same time browse various aspccts of the running programs, for example, the current stack of methods, the source code and instance variable values for the currently selected method, and of course the application user interface. The user can edit a method and immediately’ see the changed code and its effects on application execution. Our target user population is experienced procedural programmers with some awareness of objectot-ientcd concepts: the C, Pascal, or Basic progratnmcr who has read or chatted with colleagues about “tncssage passing, n “inheritance,” and so forth, but who has not yet tried to con.struct an interactive Smalltalk application. We assumed that such learners would already know a great deal about problemsolving with formal representations, that they would already know about functions, variables, control relationships, etc. Thus, we did not address learning the syntax and semantics of Smalltalk code per se. At this level, the differences between Smalltalk and conventional languages are relatively modest. What these programmers need, we conjectured, is an activity through which to concretize and develop the new view of computation as communicating objects. We designed the View Matcher for ‘learning by doing.” The sample applications we provided are meaningful and highly interactive. Programmers can leverage off their prior, real world understandings of gomoku, for example, to make sense of the Smalltalk implementation. The applications are scaffolded [3]

431

CHI 90 F’tmeedngs so that simpler structures (t.he recipe browser) can be tackled before more complex ones (gomoku). For the gomoku application, we deliberately created a cheating behavior, to better pique the :programrner’s curiosity about how the application works. Our idea was that having a variety of coordinated dynamic views available simultaneously would help programmers coordinate their developing understanding of Smalltalk and its environment. For example, we conjectured that such “matched” views might be quite useful in l.earning the model-viewcontroller (MVC) paradigm (in S:malltalk/V, modelpane-dispatcher). The MVC paradigm separates the underlying logic of an application (the model) from its user interface display (view) (and input handler (controller). Understanding how an interactive application works necessarily involves understanding all three components of the MVC and their messageprotocols, but this can involve enormous search and diagnosis. Tools like the Class Hierarchy Browser support this to some extent through hypertextual navigation of all senders or implementors of a given message. IIowever, because Smalltalk is polymorphic, the same message can often be sent to several different classes of objects; because of dynamic binding, the class of the receiver is not determined until run-time. Accordingly, a static analysis of methods associated with an object often cannot unambiguously determine which other classes of objects it interacts with during the course of a particular computation. These complexities are well recognized, albeit only implicitly. For example, a telling fact about Smalltalk is that although its capabilities for programming user interface interaction and display are powerful, these topics are frequently delayed in teaching Smalltalk (e.g., [ 111). They are delayed bccause of the difficulties inherent in exploring how user interface transactions are implemented. The View Matcher permits an application to be browsed as it is run, allowing the MVC protocol dynamics to be interactively browsed and analyzed. In addition to supporting learners’ analysis of the dynamics of computation via communicating objects, the View Matcher was designed to enhance familiarity with the general Smalltalk environment. The tools incorporated in the View Matcher are dcrived directly from the major system tools in Smalltalk (the Class Hierarchy Browser, the Inspector and the Debugger). Thus, working with the View Matcher should produce learning that transfers to the general Smalltalk environment. Second, because the various tools are permanently displayed in the View Matcher, beginners can find the important tools and can avoid low-level display management problems in using them (e.g., losing things under the active window). Finally, because the various tools incorporated into the View Matcher are jointly updated, the programmer can see the relevant temporal and causal relations among events in the tools, and more rapidly extract the regularities. The programmer can better

432

Apill

use an understanding of one tool to develop an understanding of another. MULTIPLE: VIEWS OF A TASK

Figure 1 displays a View Matlcher browser for the recipe database application; the panes in the View Mat.chcr window present various views onto the application. The Application View in the upper right of the View Matcher window displays the application interface. For the recipe database, this consists of a window w:ith two panes, a list pane and a text pane. The list pane displays a set of recipe names and, when one of these is selected, the text pane displays a recipe text. Usera can also add, delete, and edit recipes. The View Matcher does not alter the graphics or execution of the application it presents; the Application View acts exactly as it would were the application to be started without the browser (the application runs in its own window). In the upper left, is the Stack View, a list pane that displays the methods currently waiting to execute. As in the Smalltalk/V debugger, the parenthesized names to the left of the angle brackets in the method stack specify the classes that define these methods. So, for example, a RecipeMatcher object from the Object class description. inherits perform: The names to the right of the angle brackets are the names of the methods that are being invoked. ‘I’hc View Matcher updates the Stack View whencvcr the expression self displayStack occurs in the currently-executing method. In an earlier implementation of the View Matcher, we did not display this code to the user. IIowever, we like the fact that the user can see when: execution is halted and the stack is displayed, and indeed can alter this during the application’s executilon. We feel this is more in the spirit of Stnalltalk and an aid to selfinitiated learning. The key task. in installing an application under View Matcher is to distinguish certain methods as itnportant points in the execution of the application, and to designate these for display in the method stack. For example, to support exploratory learning of the MVC paradigm, we have designated all model methods that effect visible changes to the intcrfacc. ‘I’hc stack can be displayed in two modes, Halt and Animate (selected via the I-I and A buttons in the View Matcher title bar). IIalt mode stops the application each time a self displayStack is executed. The user may select “resume” in the Stack View’s pant menu to continue, or may explore the state of the application via the other View Matcher views (see below). Animate mode displays the same method stack as IIalt mode, but places each method on the stack as it begins execution and removes it when it ftishes execution. Thus, the user can interact with the application without Halt interruptilons and “watch” the execution of each user interface interaction (at the level of message sends). We update only the Stack View and t.he Application View in animate mode, since updating all the views was visually too confus-

Reci~estObjec~~>>perform: ListPane>>update ListPaneCSubPaneB>>update: tl in RecipesCObject)>>changed: OrderedCollection>>do: Recipes>channed:

Scones

lince

Preheat

ListPaneCPGneB>>pGpUp:at: ListPaneCPane>>>popUp: ListPaneCSubPaneJ>>performHenu

3cups 2 l/2 1 tsp t tbsp A/4 lb

L 1p.

-4

Dispatcher

m@wr--

pies

Recipes F emember that the f Inkiness

l -

..I

I?

l

the

of the

amount the bisc oven

to

flour tsps baking pou salt sugar butter Cl stic

I

deleteRecipe

a3 name CI b naw recipe and adde: ths uaclrt respans to tha class uariabla RecipeDictionary. Than, it informs tha rscipaListPans that tha list has changed 6~1 tha new recipe list-wil bs displayed in ths pane. asks ths The m&had thsn liist pane ta highlight the new recipe name.

sllictianary

add:

CAssaciatian

value: #recipaInfo: self changed: recipaListPana ra~tar&alacted: self displaystack.

4

key: >changed: to investigate the changed: method. The Commentary View explains that this method is used by models to inform their panes to update themselves. It explains the mechanism whereby panes become. registered as depen-

April 1990

CHI 90 Procee&nrs dents of the model, in this case RecipeMatcher, and method results in all these dethat the changed: pendents (panes) being sent the update: message, along with the identical argument, aSymbol. Selecting aSymbol in the Inspector View, the user confirms that the argument’s value is #recipeList _ Selecting the ListPane

(SubPane)

>>update

:

entry in the stack, the user obtains a coordinated view onto the recipe list pane’s reception of the update: message. The Commentary View explains that each pane which receives the update: message essentiahy asks itself “Is this update for my pane?” It does so by comparing the argument, aSymbol to the panes instance variable name --- if they are equal, the pane’s update method is invoked. The commentary describes how name is specified by the model and further that it serves two functions: it provides the internal name for the pane as well as the name of the method in the model which must be invoked to supply the contents of the pane. The Inspector View codiis that both the ListPane’s name and aSymbol are #recipeList.

The user continues tracing the execution by selecting ListPane>>update in the method stack. The associated commentary explains that a ListPane’s update method asks the model for a new list and then redraws the pane. In the Class I-Iierarchy View, the user seesthat the first Smalltalk expression in this method is list := model perform: name. By in the stack, and browsing the selecting perf arm: various views, the user learns that ListPane’s update uses the method perform: to send the message recipeList

to the model.

This will supply the list

derived from RecipeDictionary to the recipe ListPane. The user’s question is answered, and through the course of pursuing the question the user has discovered some very fundamental aspects of the MVC paradigm: the self mechanism for changed: controlling the updating of a model’s view, the use of the name instance variable to link MVC depcndencies, as well as the role of perform: in communicating between the model and view. The user’s original goal in this scenario was to sort the recipe list alphabetically instead of chronologically. The user determined that recipeList provides the ListPane’s contents. In that the Smalltalk method expression RecipeDictionary

keys

asOrderedCollection

creates an unsorted list of recipes, and the user can modify the expression to return the list asSortedCollection instead. The consequences of this change can be verified immediately by resuming the application. INTERPOLATING

A GOMOKU

MOVE

In the tic-tat-toe and gomoku games, the user “moves” by pointing and selecting a square on the gameboard. The user might wonder, how does the game resolve move positions? In Figure 2, the gomoku game has halted after a player-move, during the execution of graphselect:. The user investigates the GraphDispatcher (the controller) methods in the stack and discovers that a mouse selection

causes the message selectAtCursor to be sent to to the GraphPane (the view). In the figure, the user has selected selectAtCursor in the Stack View; the GraphPane class and the selectAtCursor method are highlighted in the ClassHierarchy View and the text of the method is displayed; the GraphPane object appears in the Inspector View. The Commentary View explains that it is the selectAtCursor method which informs the model of a mouse click within the GraphPane: when the mouse button is released, the message whose selector is the value of the instance variable selectup is sent to the model. (The commentary also explains how the model tells the GraphPane to have selectup point to a particular message name.) By looking at the coordinated method text in the Class Hierarchy View, the user can puzzle out the Smalltalk code that implements this reIationship. The user must still determine how the graphselect: message gets sent to the model, and what argument is sent with this message. The user inspects the GraphPane object in the Inspector View to gain access to its instance variables: the content instance the variable selectup is of The text of the selectAtCursor #graphSelect:. method in the Class Hierarchy View shows that the variable selection provides the argument of graphselect

2.

Turning

again to the

Inspector

View, the user selects this variable and discovers that the contents of selection is a Point. But what Point? The method text for selectAtCursor shows that this point is set to the current cursor position (this portion of the text is not visible in the figure). Thus, the argument sent with the graphselect: method is the point at which the user released the mouse button. The user has worked through the interactious among a GraphDispatcher, a GraphPane, and a model, in which the model becomes informed of a user mouse click within the pane. DEVELOPING

SKILL IN SMALLTALK

Little work on programming environments has been directed toward the task of iearning to program (e.g., [I] but cf. [2]). We want to enable users to more conveniently map interactive application behavior onto irnplemcntation detail. We want to take advantage of the prior understanding people have of our applications to motivate and orient learning by discovery . We want them to see the major Smalltalk system tools simultaneously displayed, to cause them to be jointly updated in the course of exploring the applications, and to infer how the different views can be resolved and integrated. ‘I’hc View Matcher is a programming environment designed for self-directed learning. The View Matcher does not prescribe activities or sequences of activities. It recruits the resources of the system itself as the basis for an integrated, exploratory learning environment. It coordinates these resources to provide multiple, dynamic views of concrete example applications that already make sense to the user. It

435

GoVloku>>nraphSelect: GoHoku~Oj;ject))>perfor":"ith: . ispatc er process unctionKey: rap GraphDispatcher~Dispatcher)))proce~sKey GraphDispatcherCDispatcher>>>processInp TopDispatcher[Dispatcher>>>searchForAct TopDispatcher~Dispatcher)))activateWind Dispat&hHanager>>;un

IL '-&

GraphPane

Dispatcher GoHove

GoHoku Pane SubPane

L rt

Iv

scm11Up:

se ect aon: IselectUp:

.

ahs '~alactAtCur~ar' mstha hf a GraphPane informs tha mods1 whan and whara a moute click LSCCU~~Swithin tha GraphPane. Whsn the rnous6 buttfin i;s releaBBdJ IF the modal has specified mathad a 's~lactUpJ selector