INFORMATION MODELS, VIEWS, AND CONTROLLERS

Adele Goldberg

We have all experienced the benefits of reuse in every aspect of life. For example, when traffic control signs are reused throughout a city, a state, and even internationally, our ability to navigate streets and highways is helped. Reuse of text editors and picture editors across applications on the same or different hardware systems improves our ability to use those applications. The value of a graphing or diagramming technique increases with the number of ways it can be reused on different data, thereby improving our ability to quickly analyze new kinds of data. Reuse benefits the user as well as the application developer.

In the context of software applications, to reuse a software component generally means keeping it the same, while changing the context or style in which it is used. Text, for example, might stay the same, while the fonts and document layout containing that text might vary; data might stay the same, but it might be presented differently in terms of graphs, pie charts, tables, or animations; or the ways of presenting information might stay the same, while the techniques for making selections and issuing commands might be different.

One major area of software development that can benefit from reusable software is the design and implementation of applications having graphical user interfaces. As a consequence of the widespread availability of bit-mapped displays, the attention of many programmers shifted from emphasis on implementing models of data, transactions, and/or business functions, to creating appealing user interfaces. Requirements for adhering to the many user interface standards have not decreased the importance of seeking innovative ways to present information on the display screen and to support users in accessing and manipulating that information.

Because reusability of user components is a key element in improving the productivity of software developers, an important question to answer is which software components should be targeted for reuse? This article answers the reuse question through a review of the implementation architecture called "Model-View-Controller" (MVC) that is available to application developers using the Objectworks for Smalltalk-80 program development system developed by ParcPlace Systems. The intent of the article is to demonstrate the advantages of this architecture in developing graphical interactive applications.

The Model-View-Controller architecture for the Objectworks for Smalltalk-80 system was designed specifically to help programmers create graphical user interfaces through the reuse of software components that represent the presentation and interaction aspects of an application. The use of object-oriented software was essential in motivating the design for MVC and was the basis for its implementation.

One way to improve productivity in software development is to reuse user interface designs across different applications. Another entails leveraging special support for multiple ways of viewing and interacting with an information model in accordance with diverse user preferences. For example, some users might want to view their data as tables of numbers, while others might prefer graphs, descriptive text, or animations. These alternatives might be mapped onto a set of software components that can be attached interchangeably to a common information model. The information model is then shared among the projects requiring the different graphical interfaces. The development effort and cost involved in implementing the information model is incurred just once. Many different information models can be presented with similar user interfaces.

Recognizing and exploiting these opportunities for reuse led to the design of two kinds of elements in Objectworks for Smalltalk-80 -- a library of presentation and interaction components, and a set of tools supporting a methodology for linking presentation and interaction components to underlying information models. These kinds of elements provide the basic building blocks for the MVC architecture.

"Model" refers to a representation of the application domain as an information model, while "view" is a specification of how aspects of a model are presented to the user. The "controller" is the specification of how the user can communicate or interact with the application in order to request changes in the view or in the underlying model. Consider, for example, a real-time clock that is to appear on the display screen. The information model is an object representing DateAndTime, which is implemented in terms of the computer hardware's built-in clock. Suppose DateAndTime can report the current time of day and the name of the current day of the current month. On the screen, DateAndTime might appear as a digital watch in which the day and month are printed on one text line and the hours:minutes:seconds appear, constantly updated, on a second text line. This text-oriented presentation is the "view" of the model DateAndTime.

Another view might be of an analog clock, with a second hand moving around, ticking off seconds. Perhaps the user has direct access to resetting the time information. In the textual view, the user could select the text of hours:minutes:seconds with a pointing device such as a mouse and then use a text editor to modify the visible information. This in turn would modify the underlying DateAndTime model, and the change would be reported back to the view that is an analog clock for immediate update. The user's ability to text edit is handled by a "controller."

The design of the MVC roles in Smalltalk-80 came about as a result of a two-stage factoring. First, the design and implementation of the domain-specific aspects (the model) is separated from work on the user interface. Second, the user interface is divided into presentation and interaction aspects.

The ideal scenario for the construction of application software under the MVC paradigm begins by focusing on the design and implementation of the information model components of an application. (Even here, there are substantial opportunities for reuse from previous projects.) Once the underlying model is completed, the developers reach into a library of reusable user interface components and select (and tailor) various graphical presentations and styles of user interaction appropriate for the target users' preferences. In this way, it is possible to create several implementations quickly, varying the presentation and interaction styles according to user needs. In our experience, it is common for the underlying model and presentation style to stay fixed across a broad set of end users, whereas interaction style (such as typing commands versus command keys, or the selection of icons) varies considerably. By separating the notion of presentation from interaction, this disparity can be accommodated.

  Model
          Text
          TextCollection
                Terminal

  View
          TextView
          CodeView
                OnlyWhenSelectedCodeView

  Controller
          MouseMenuController
                ScrollController
                        TextEditor
                                CodeController
                                      AlwaysAcceptCodeController
                                      OnlyWhenSelectedCodeController

The technical history of MVC is tied to the idea that programmers are not typically trained as graphic artists nor as human-factor engineers. But the knowledge of such experts could be captured, in the form of presentation techniques and interaction frameworks, and made available in a library of reusable software components. The factoring of MVC draws attention to particular kinds of components that should be made available for reuse in order to take advantage of the knowledge of these experts.

Two programming techniques are needed to support such reuse: Composition and refinement. Composition entails combining existing elements to create something new. Objectworks for Smalltalk-80 supports two kinds of composition: Composition via delegation, stating that a newly created object has properties that refer to (instances of) existing classes (an action that requires manipulation of these properties is delegated to the appropriate object); and composition via dependency, stating that an instance of one class depends on the change in behavior of (instances of) another class.

Additionally, two kinds of refinement are supported: Refinement via inheritance (subclassing), stating that a newly created object acquires the properties, protocol, and implementation of the protocol, of an existing class; and refinement via parametrization, stating that a new object is an instance of an existing class of objects by filling in details about the properties that distinguish this instance from other instances of the class.

Through composition, you can reuse existing models (that correspond to generic objects), existing views, and controllers that define a look and feel for the user interface and existing tools, for example, a text editor or document outline browser.

Through refinement, you can reuse existing application-building frameworks that encompass sets of views and controllers, as well as parametrisizable models. You can also reuse existing parameterizable, tailorable complete applications.

Through composition and refinement, object-oriented MVC design allows the software analyst/designer to focus on creating components that are immediately reusable and that provide for future incorporation of new views, controllers, and/or models.

  Class                     Function
---------------------------------------------------------------------------

  Form                      Represents a rectangular pattern of dots.

  Text                      Represents a string of displayable characters
                            with emphasis and font change.

  Switch                    Represents a selection setting and actions to
                            take on a change in the setting.  A Switch has
                            three attributes: state (either on or off); on
                            action; and off action.  The on and off actions
                            are blocks of code that execute whenever the
                            Switch changes state.

  Button                    A Switch that turns off automatically after
                            being turned on, that is, it acts like a
                            push-button switch.

  SwitchView and            The view presents a switch on the display
  SwitchController          screen, showing a label when the switch is off
                            and showing a special highlight form when the
                            switch is on; the controller knows a message to
                            be sent to the Switch whenever it is selected.

  PopUpMenu                 Represents a list of items presented on the
                            display screen in a rectangular area.  As the
                            user points to an item, pressing a mouse
                            button, the item is highlighted; when the
                            button is released, the last highlighted item
                            is the selection.

  MouseMenuController       Whose behavior is to check for user mouse
                            button events and invoke an action according to
                            which button is pressed.

  StandardSystem/View and   A presentation of a simple window with a title
  StandardSystemController  label above the top left corner, whose behavior
                            is to move, reframe, collapse, and close.

Three primary advantages derive from adopting the MVC approach and using it to factor graphical interactive applications. The advantages are: Multiple Viewing, Development Productivity, and Quality. Let's look at each briefly.

Multiple Viewing. Factoring the underlying model from its graphical presentation and interaction allows the programmer to couple the model to several alternative interfaces. Objectworks for Smalltalk-80 provides special support for objects to exchange information about changes. Whenever an object changes, it broadcasts a message that it has changed and what aspect (property) has changed. By combining this support for dependency relationships with the factoring of views and controllers from the underlying model, several views of the same model can be interacted with simultaneously on the same display.

Development Productivity. As noted earlier, it is often possible to create new views and controllers as refinements of existing ones, while retaining the underlying information models. It is also often necessary for the programmer only to implement specific kinds of models that fit into existing user interface designs. Therefore, taking advantage of the reusability of existing MVC components and frameworks can reduce significantly the amount of programming necessary for completing an application development project.

The programmer must be aware of the contents of the available libraries of reusable components and have tools for locating and experimenting with those components. Objectworks for Smalltalk-80, for example, provides the system source code browser with MVC components carefully organized into categories. Each of the program development tools provided with the product are created using the MVC approach. The programmer can inspect the implementation of these tools using the ParcPlace debugger and special MVC inspector.

MVC factoring also facilitates the programmer's ability to respond to new technology for special physical needs or interaction media. For example, this factoring makes it a simpler task to utilize voice output instead of printed text on a display screen. Only the presentation aspects of an MVC-style application would change, not the underlying model.

Quality. Reusing existing components allows those components to become more mature and, therefore, more robust as they are tested in new situations. Reusing existing designs supports the acquisition of the expertise that might not otherwise be available. And improved productivity allows for more experimentation and testing.

MVC was first explored and tested in earlier versions of the Objectworks for Smalltalk-80 system. It was designed to enable reuse of classes representing views and controllers, with models that were otherwise nongraphical. The current implementation was designed with assumptions about the sophistication of the programmer who is able to reuse components from an extensive library. The desire for uniformity of software architecture encouraged the application of the MVC design concepts to text and picture editors, creating considerable experimentation and discussion about the idea of splitting techniques of selection, scrolling, and zooming from these underlying graphical entities. The original MVC was not designed to deal specifically with underlying models that are themselves graphical in nature. We were primarily trying to support visualization of simulations written in Smalltalk-80, itself designed as a language that supports general-simulation descriptions. Over years of use, we have discovered simplifications and new abstractions that make these performance and implementation issues easier to understand. New improvements will appear in subsequent releases of Objectworks for Smalltalk-80.

_INFORMATION MODELS, VIEWS, AND CONTROLLERS_ by Adele Goldberg