A Description of the Model-View-Controller User
`Interface Paradigm in the Smalltalk-80 System
`
`Glenn E. Krasner and Stephen T. Pope
`ParcPlace Systems, Inc.
`
`1550 Plymouth Street Mountain View, CA 94043 glenn@ParcPlace.com
`
`Copyright © 1988 ParcPlace Systems. All Rights Reserved.
`
`Abstract
`This essay describes the Model-View-Controller (MVC) programming paradigm and
`methodology used in the Smalltalk-80TM programming system. MVC programming is the
`application of a three-way factoring, whereby objects of different classes take over the operations
`related to the application domain, the display of the application's state, and the user interaction
`with the model and the view. We present several extended examples of MVC implementations and
`of the layout of composite application views. The Appendices provide reference materials for the
`Smalltalk-80 programmer wishing to understand and use MVC better within the Smalltalk-80
`system.
`
`Contents
`Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
`MVC and the Issues of Reusability and Pluggability . . . . . . . . . . . . . . . . . 2
`The Model-View-Controller Metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
`An Implementation of Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . 5
`User Interface Component Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
`Program Development Support Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`View/Controller Factoring and Pluggable Views . . . . . . . . . . . . . . . . . . . . 16
`MVC Implementation Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
`Counter View Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
`Hierarchical Text Organizer Example . . . . . . . . . . . . . . . . . . . . . . . . . . 24
`FinancialHistory Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
`Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
`Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
`References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
`Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
`RPX Exhibit 1110
`RPX v. AIT
`
`1
`
`

`
`Introduction
`The user interface of the Smalltalk-80 programming environment (see references, [Goldberg,
`1983]) was developed using a particular strategy of representing information, display, and control.
`This strategy was chosen to satisfy two goals: (1) to create the special set of system components
`needed to support a highly interactive software development process, and (2) to provide a general
`set of system components that make it possible for programmers to create portable interactive
`graphical applications easily.
`
`In this essay, we assume that the reader has basic knowledge of the Smalltalk-80 language and
`programming environment. Interested readers not familiar with these are referred to [Goldberg
`and Robson, 1983] and [Goldberg, 1983] for introductory and tutorial material.
`
`MVC and the Issues of Reusability and Pluggability
`When building interactive applications, as with other programs, modularity of components has
`enormous benefits. Isolating functional units from each other as much as possible makes it easier
`for the application designer to understand and modify each particular unit, without having to
`know everything about the other units. Our experiences with the Smalltalk-76 programming
`system showed that one particular form of modularity--a three-way separation of application
`components--has payoff beyond merely making the designer's life easier. This three-way division
`of an application entails separating (1) the parts that represent the model of the underlying
`application domain from (2) the way the model is presented to the user and from (3) the way the
`user interacts with it.
`
`Model-View-Controller (MVC) programming is the application of this three-way factoring,
`whereby objects of different classes take over the operations related to the application domain (the
`model), the display of the application's state (the view), and the user interaction with the model
`and the view (the controller). In earlier Smalltalk system user interfaces, the tools that were put
`into the interface tended to consist of arrangements of four basic viewing idioms: paragraphs of
`text, lists of text (menus), choice "buttons," and graphical forms (bit- or pixel-maps). These tools
`also tended to use three basic user interaction paradigms: browsing, inspecting and editing. A goal
`of the current Smalltalk-80 system was to be able to define user interface components for
`handling these idioms and paradigms once, and share them among all the programming
`environment tools and user-written applications using the methodology of MVC programming.
`
`We also envisioned that the MVC methodology would allow programmers to write an application
`model by first defining new classes that would embody the special application domain-specific
`information. They would then design a user interface to it by laying out a composite view
`(window) for it by "plugging in" instances taken from the predefined user interface classes. This
`"pluggability" was desirable not only for viewing idioms, but also for implementing the
`controlling (editing) paradigms. Although certainly related in an interactive application, there is
`an advantage to being able to separate the functionality between how the model is displayed, and
`
`2
`
`

`
`the methods for interacting with it. The use of pop-up versus fixed menus, the meaning attached to
`keyboard and mouse/function keys, and scheduling of multiple views should be choices that can
`be made independently of the model or its view(s). They are choices that may be left up to the
`end user where appropriate.
`
`The Model-View-Controller Metaphor
`To address the issues outlined above, the Model-View-Controller metaphor and its application
`structuring paradigm for thinking about (and implementing) interactive application components
`was developed. Models are those components of the system application that actually do the work
`(simulation of the application domain). They are kept quite distinct from views, which display
`aspects of the models. Controllers are used to send messages to the model, and provide the
`interface between the model with its associated views and the interactive user interface devices
`(e.g., keyboard, mouse). Each view may be thought of as being closely associated with a
`controller, each having exactly one model, but a model may have many view/controller pairs.
`
`Models
`The model of an application is the domain-specific software simulation or implementation of the
`application's central structure. This can be as simple as an integer (as the model of a counter) or
`string (as the model of a text editor), or it can be a complex object that is an instance of a subclass
`of some Smalltalk-80 collection or other composite class. Several examples of models will be
`discussed in the following sections of this paper.
`
`Views
`In this metaphor, views deal with everything graphical; they request data from their model, and
`display the data. They contain not only the components needed for displaying but can also
`contain subviews and be contained within superviews. The superview provides ability to perform
`graphical transformations, windowing, and clipping, between the levels of this subview/superview
`hierarchy. Display messages are often passed from the top-level view (the standard system view of
`the application window) through to the subviews (the view objects used in the subviews of the tool
`view).
`
`Controllers
`Controllers contain the interface between their associated models and views and the input devices
`(keyboard, pointing device, time). Controllers also deal with scheduling interactions with other
`view-controller pairs: they track mouse movement between application views, and implement
`messages for mouse button activity and input from the input sensor. Although menus can be
`thought of as view-controller pairs, they are more typically considered input devices, and
`therefore are in the realm of controllers.
`
`3
`
`

`
`Broadcasting Change
`In the scheme described above, views and controllers have exactly one model, but a model can
`have one or several views and controllers associated with it. To maximize data encapsulation and
`thus code reusability, views and controllers need to know about their model explicitly, but models
`should not know about their views and controllers.
`
`A change in a model is often triggered by a controller connecting a user action to a message sent
`to the model. This change should be reflected in all of its views, not just the view associated with
`the controller that initiated the change.
`
`Dependents
`To manage change notification, the notion of objects as dependents was developed. Views and
`controllers of a model are registered in a list as dependents of the model, to be informed whenever
`some aspect of the model is changed. When a model has changed, a message is broadcast to notify
`all of its dependents about the change. This message can be parameterized (with arguments), so
`that there can be many types of model change messages. Each view or controller responds to the
`appropriate model changes in the appropriate manner.
`
`A Standard for the Interaction Cycle
`The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes
`some input action and the active controller notifies the model to change itself accordingly. The
`model carries out the prescribed operations, possibly changing its state, and broadcasts to its
`dependents (views and controllers) that it has changed, possibly telling them the nature of the
`change. Views can then inquire of the model about its new state, and update their display if
`necessary. Controllers may change their method of interaction depending on the new state of the
`model. This message-sending is shown diagrammatically in Figure 1.
`
`4
`
`

`
`Figure 1: Model-View-Controller State and Message Sending
`
`An Implementation of Model-View-Controller
`The Smalltalk-80 implementation of the Model-View-Controller metaphor consists of three
`abstract superclasses named Model, View, and Controller, plus numerous concrete subclasses. The
`abstract classes hold the generic behavior and state of the three parts of MVC. The concrete
`classes hold the specific state and behavior of the application facilities and user interface
`components used in the Smalltalk-80 system. Since our primary set of user interface components
`were those needed for the system's software development tools, the most basic concrete
`subclasses of Model, View, and Controller are those that deal with scheduled views, text, lists of
`text, menus, and graphical forms and icons.
`
`Class Model
`The behavior required of models is the ability to have dependents and the ability to broadcast
`change messages to their dependents. Models hold onto a collection of their dependent objects.
`The class Model has message protocol to add and remove dependents from this collection. In
`addition, class Model contains the ability to broadcast change messages to dependents. Sending
`the message changed to a Model causes the message update to be sent to each of its dependents.
`Sending the message changed: aParameter will cause the corresponding message update:
`aParameter to be sent to each dependent.
`
`A simple yet sophisticated MVC example is the FinancialHistory view tutorial found in
`[Goldberg and Robson, 1983]. A display of a FinancialHistory is shown in Figure 2 and its
`implementation is discussed in the MVC implementation examples at the end of this essay. In it, a
`view that displays a bar chart is created as a dependent of a dictionary of tagged numerical values
`
`5
`
`

`
`(for example, rent --> $500). The composite FinancialHistoryView has two subviews, with two
`bar charts, whose models are two distinct dictionaries (incomes and expenditures). These are held
`as instance variables of the central model, an instance of class FinancialHistory.
`
`Figure 2 also shows the pop-up menu used by the FinancialHistoryController with the two items
`labeled 'spend' and 'receive' as well as the input prompter (a FillInTheBlank) querying for an
`amount to be spent on 'good times'.
`
`Figure 2: FinancialHistoryView with its BarChart subviews, the Controller's menu, and an
`interaction prompter (note that the menu and prompter are never visible at
`the same time)
`
`User action for interacting with the FinancialHistory application might be to pick an item from a
`menu to add a new amount for rent. The controller then sends a message to the model (the
`dictionary), and the model sends self changed. As a result of this, the bar chart is sent the
`message update. In response to that message, the bar chart gets the new values from the
`dictionary and displays the new bars using the display messages.
`
`A flow diagram for this MVC interaction might be:
`
`6
`
`

`
`Figure 3: Message-sending and dependency updating for an example from the
`FinancialHistory application
`
`The change messages with parameters (i.e., self changed: someAspect) are used to pass
`information from the model to its dependents about which aspect has changed, so as to minimize
`the amount of view updating needed. For example, the object householdFinances (the model
`mentioned earlier that holds onto the dictionaries of income and expenses), could have been the
`model of two bar chart views, with separate protocols for displaying expenses and income. In this
`case, the update message could contain a parameter saying which of the aspects (expenses or
`income) had changed.
`
`Depending on the application, many of the basic Smalltalk-80 system structure classes can serve as
`models of MVC systems. Views can be found in the system or user applications that use very simple
`objects (numbers or strings), collection class instances (orderedCollections, dictionaries, bitmaps or
`display-Texts) or complex composite objects (networks, databases, event lists or financial histories) as their
`underlying models.
`
`Class View
`The abstract superclass, class View, contains the generic behavior of views in the system. This
`includes model and controller interaction, subview and superview interaction, coordinate
`transformation, and display rectangle actions. The many subclasses of View implement the
`various display interaction tools used in the user interface.
`
`Every instance of a view has exactly one model and exactly one controller. The model is normally
`set explicitly. Because view and controller classes are often designed in consort, a view's
`controller is often simply initialized to an instance of the corresponding controller class. To
`support this, the message defaultControllerClass, that returns the class of the appropriate
`controller, is defined in many of the subclasses of View.
`
`7
`
`

`
`Views have the ability to have zero or more subviews, with flexible coordinate transformations
`between one view and its super- and subviews. Instances of class View have instance variables for
`their superviews and for a (possibly empty) collection of subviews, as well as for an instance of
`class WindowingTransformation which represents the transformation (translation and scaling)
`between that view's coordinate system and that of its superview. In addition, there is a default
`protocol in View for adding and removing subviews, as well as a protocol for changing the
`transformations. This allows views consisting of many subviews to be pieced together flexibly
`and simply.
`
`The third type of behavior in class View is that which relates to displaying. Because subclasses of
`View are assumed to use display objects to actually do their displaying (Forms, Pens, Lines or
`instances of other graphical classes), View only supports generic displaying behavior. In
`particular, there is no instance variable for display objects. Class View assumes that the top level
`of a subview structure displays on some medium (typically the display screen).
`
`Views therefore cache the transformation from their own internal coordinate system to the
`display's coordinate system (i.e., the composition of the view's transformation and all of its
`superviews' transformations), so that it is faster to get from a view's internal space to display
`space. View also has instance variables insetDisplayBox, the clipping rectangle within which the
`view may display without overlapping other views; borderWidth and borderColor, to define the
`(non-scaled) borders between a view and its superview, insideColor, to define the color (if any)
`with which a view colors its insetDisplayBox before actually displaying its contents; and
`boundingBox, to describe the extent of display objects within the view's coordinate system.
`
`By default, the message model: anObject, when sent to a view, initializes the view's controller to
`be a new instance of the view's default controller class. It establishes anObject as the model for
`both the view and the controller, and establishes the view as a dependent of the model. This one
`message is typically sufficient for setting up the MVC structure.
`
`The message release, used when closing a hierarchy of views (i.e., the sub-views of one top-level
`window), gives the programmer the opportunity to insert any finalization activity. By default,
`release breaks the pointer links between the view and controller. The message release also
`removes the view from its model's dependents collection, breaking reference circularities between
`them.
`
`Class Controller
`It is a controller's job to handle the control or manipulation (editing) functions of a model and a
`particular view. In particular, controllers coordinate the models and views with the input devices
`and handle scheduling tasks. The abstract superclass Controller contains three instance variables:
`model, view, and sensor, the last of which is usually an instance of class InputSensor representing
`the behavior of the input devices.
`
`8
`
`

`
`Because the interpretation of input device behavior is very dependent on the particular
`application, class Controller implements almost none of this behavior. The one such behavior that
`is implemented is the determination of whether or not the controller's view contains the cursor.
`
`Class Controller does include default scheduling behavior. It takes the point of view that only one
`controller is to be active at a time; that is, only one controller at a time mediates user input actions.
`Other views could be displaying information in parallel, but the user's actions are to be interpreted
`by a single controller. Thus, there is behavior in class Controller for determining whether a
`controller needs to receive or maintain control. In addition, there is behavior to signal initiation
`and termination of control, since many controllers will need to have special initiation and
`termination behavior.
`
`The query messages isControlWanted and isControlActive are overridden in concrete subclasses of
`Controller if they require a different behavior for determining whether to receive or maintain
`control. By default, these messages use the messages controlToNextLevel (pass it on down) and
`viewHasCursor (a query) in such a way that the controller of the lowest subview in the hierarchy
`that contains the cursor in its display box will take and retain control.
`
`Once a controller obtains control, the default behavior is to send it the messages controlInitialize,
`controlLoop, and controlTerminate. This message sequence is found in the method startUp. The
`messages controlInitialize and controlTerminate are overridden in subclasses that want specific
`behavior for starting and ending their control sequences (for example, many of the list controllers
`have a scroll bar appear to their left only when they have control). controlLoop is implemented as
`a loop that sends the message controlActivity as long as the controller retains control. This
`message is overridden in many controller classes to do the "real" work of the user interface.
`
`StandardSystemView and StandardSystemcontroller
`Subclasses of View and Controller are the various classes that implement more specific types of
`view and controller behavior. Classes StandardSystemView and StandardSystemController are the
`implementation of "window system" behavior. StandardSystemController contains the definition
`of the standard blue-button menu (normally assigned to the right-hand mouse button), used for
`accessing operations of closing, collapsing, and resizing the top-level view on the display. It also
`contains the behavior for scheduling the view as one of the active views. StandardSystemView
`contains the behavior for top-level view labels, for displaying when collapsed or not (possibly
`using icons), and for the size (minimum, maximum, changing) of the view on the display.
`Interactive applications typically exist inside system views, that is, the views and controllers for
`the application are created as subviews of a StandardSystemView (the application's top-level
`view).
`
`In addition to StandardSystemController, the system provides other abstract controller classes
`with default behavior. Instances of NoController will never take control; they are often used in
`conjunction with "read-only" views. Class MouseMenuController includes behavior for
`
`9
`
`

`
`producing pop-up menus when any of the mouse buttons is pressed. Most controllers in the user
`interface are subclasses of MouseMenuController, including StandardSystemController itself,
`because of the extensive use of pop-up menus. Another example of these abstract classes is class
`ScrollController, which implements scroll bars.
`
`Because views are often composed of parts (composite views), with one application view
`containing multiple subviews (as the FinancialHistoryView shown in Figure 2 has subviews for
`the two bar chart views), the instance variables for views have different meanings in an
`application's StandardSystemView than in their subviews. Of the many subclasses of View, some
`are meant to behave as top-level views (such as StandardSystemView), and others are meant to be
`used as subviews (single subviews within a structured view) and "plugged in" to other views as
`components (such as the SelectionInListViews used in many types of applications).
`
`Figure 4 is a schematic diagram of the state and interrelationships of the relevant MVC objects
`used in the CounterView example showing the values of some of their variables. The complete
`source code for this example is included below in the section called "MVC Implementation
`Examples." The interdependencies are shown by the arrows linking the model, view and
`controller together via instance variables and dependents.
`
`Figure 4: Instance variables of an MVC Triad for a running CounterView
`
`User Interface Component Hierarchy
`The classes View and Controller, along with the other abstract classes, provide the framework for
`views and controllers in the Smalltalk-80 implementation of the Model-View-Controller
`metaphor. The system also contains various subclasses of View and Controller that provide the
`pieces of user interface functionality required by interactive applications. These user interface
`components include menus, text, and forms. These components are pieced together to form the
`standard system views of the Smalltalk-80 application development environment, and can be
`reused or subclassed for system applications. They form the kernel of the component library of
`model-building tools and user interaction components that can be easily "pulled off the shelf" and
`"plugged" together to create interactive applications. We list some of them here, but in most cases
`
`10
`
`

`
`we only use the names of the subclasses of View; it is assumed that each is used with one or more
`appropriate Controller subclasses.
`
`SwitchView and ListView are two subclasses of View that provide static or dynamic menu
`behavior. SwitchViews are used, for example, in the instance/class switch of the system browser
`or the iconic menu of the form editor. They behave as a switch; they can either be on or off, and
`when the user clicks the mouse button on them, they will notify their model. These are typically
`used as menus of text or forms, or "buttons."
`
`A ListView is a scrolling menu of text items, such as those used in the upper four subviews of the
`system browser (shown in Figure 11). It will inform its model when the user has made a new
`selection in the list. Figure 5 shows examples of the use of subclasses of SwitchViews (in the
`iconic menu of the FormEditor, the paint program) and ListViews (in the Browser's category
`subview).
`
`Figure 5: SwitchView and ListView examples
`
`Prompters and Confirmers are simple views that can be input. They are started up by giving them
`a string for their query or prompt, and can return either a string value (in the case of Prompters) or
`a Boolean value (in the case of Confirmers).
`
`Figure 6: Examples of a Prompter and a Confirmer
`
`Because they can be considered as belonging more to the controller-sensor interface, pop-up
`menus are implemented as a special kind of MVC class. Class PopUpMenu is a subclass of
`Object and provides its own scheduling and displaying behavior. They are typically invoked by a
`MouseMenuController when the user pushes a mouse button. When invoked, PopUpMenus by
`default return a numerical value that the invoking controller uses to determine the action to
`perform. There are several subclasses of PopUpMenu, some that implement hierarchical (multi-
`level) menus and others that return symbols instead of numerical values upon item selection.
`Examples of typical menus are shown in Figure 7.
`
`11
`
`

`
`Figure 7: Examples of Simple and Hierarchical Menus
`
`A number of view/controller subclasses provide text handling components. Class
`StringHolderView and class TextView provide views of text used in Workspaces, Editors,
`Transcripts and other instances where text is displayed. The Controller subclasses
`ParagraphEditor and TextEditor have the standard text editing functionality and are used in many
`text editor subviews. The layout of a file-based text editor view is shown in Figure 8 along with
`the names of its components.
`
`Figure 8: File-based TextEditorView and Menus
`
`In addition to these view types, there are several other classes provided within the system that are
`used in building MVC user interfaces. These include the special controller classes mentioned
`earlier: MouseMenuController and NoController; and the class InputSensor that is used for
`monitoring user input. There is a global object called Sensor that is the sole instance of the class
`InputSensor. It is used to model the user's input devices such as the mouse and the keyboard. One
`can send query messages to Sensor such as anyButtonPressed, or one can wait for a user action
`with messages such as waitBlueButton. One need normally never refer to Sensor, since it is used
`in the implementation of the more basic controller classes, but many types of special user
`interface components, especially those that track the mouse directly (for rubber-band lines, for
`example), use it.
`
`12
`
`

`
`Program Development Support Examples
`Workspaces, inspectors, browsers, debuggers and various editors are among the system views
`provided in the Smalltalk-80 software development support environment. They serve now as
`examples of piecing together subviews from the view and controller components collection with
`appropriate models to provide useful and flexible front-ends for interactive applications.
`
`Workspaces
`The workspaces in the system are StringHolderView/StringHolderController combinations
`installed as the single subview of a StandardSystemView. Their model is an instance of
`StringHolder, which merely holds onto an instance of Text, a String with formatting information.
`The menu messages implemented by StringHolderController correspond to the basic text editing
`and Smalltalk-80 code evaluation commands as shown in the menu in Figure 9.
`
`Figure 9: Simple Workspace View and Menu
`
`Inspectors
`The inspectors in the system are implemented as two views. A ListView contains the instance
`variable list (left side), and a TextView displays the value of the selected instance variable (right
`side). An instance of InspectorView serves as their common superview, and an instance of
`StandardSystemView serves as its superview for scheduling purposes. The model for these views
`is an instance of Inspector.
`
`Inspectors can be used to view any object. A separate class, Inspector, serves as the intermediary
`or filter for handling access to any aspects of any object. As a result, no extra protocol is needed in
`class Object. Using intermediary objects between views and "actual" models is a common way to
`further isolate the viewing behavior from the modeling application.
`
`It is possible to build a more appropriate interactive interface to composite objects by subclassing
`the inspector for use with classes such as arrays and dictionaries. There are also specialized
`inspectors for complex objects such as MVC triads themselves or application-specific classes
`such as event lists.
`
`13
`
`

`
`Figure 10: Inspector Examples - Simple, Array and Dictionary Inspectors
`
`Browsers
`As with inspectors, intermediary objects are used to model the system code browser behavior. An
`instance of class Browser is the intermediary model for each system browser, representing the
`query paths through the system class hierarchy to the class organization and the classes. As
`dependents of the Browser model, there are the four list views (for Class Categories, Classes,
`Message Protocols and Messages), a code (text) view (for the method code of the selected
`message or a class definition template), and two switch views (for selective browsing of class and
`instance messages as shown in Figure 11). Class Browser has separate protocol for each of the
`various subviews of the browsers.
`
`Figure 11: System Browser View Layout and Browser Menus
`
`Each of the subviews sends different messages to the model to query the values of an aspect of the
`system code. Each of the controllers sends different messages when the aspect should be changed.
`
`For example, when the user selects a new class in the class list subview, the controller for that
`subview sends the message className: newClassName to the Browser. The Browser sets up its
`new state accordingly. This involves sending the messages self Changed: #protocol and self
`
`14
`
`

`
`changed: #text. In response to the corresponding update: messages, the category subview, the
`class and instance switches, and the class subview do nothing. The protocol subview asks the
`Browser for the new list of protocols to display and displays it. The message list subview clears
`itself, and the text subview asks the Browser for the current text to display, which is the new class
`template. In this way, the six view/controller pairs sharing the single model work to produce the
`desired effect.
`
`There are several other types of Browser found in the Smalltalk-80 system. Note the middle group
`of menu items in the upper-right subview (the MessageList) of the System Browser shown above.
`The menu items senders, implementors and messages can be used to open new browsers (called
`Message-Set Browsers) on a small subset of the system messages-namely all the senders of the
`currently selected message, all other implementors of the same message, or all messages sent
`from within the method of the currently selected message. Other Browsers exist, for example, to
`assist in change management (ChangeSet Browsers) or system recovery (ChangeList Browsers).
`
`Debuggers
`Class Debugger is defined as a subclass of class Browser, so that it can inherit the cross-
`referencing behavior (menu messages for querying senders, implementors and messages used in a
`method). It also inherits and augments the code view behavior. The upper subview, which is a
`context list (i.e., a message-sending stack), is a list view that uses protocol defined in class
`Debugger for displaying the system's message sending context stack as a list view.
`
`Unlike the system browser, the Debugger is not the only model involved in the debugging
`application. There is a separate Inspector model for each of the two inspector subviews