This is a translation of Trygve Reenskaug’s article on May 12, 1979 when MVC was proposed.

Original MVC Report

Trygve Reenskaug, Department of Information, University of Oslo

In 1978/79, while working as a visiting scientist at Xerox Palo Alto Research Laboratory (PARC), I completed the first implementation and wrote the original MVC report. MVC was created as an obvious solution to the general problem of giving users control over their information from multiple perspectives. MVC has created amazing topics. Some texts even use distorted variations, with the opposite aim of putting the computer in control of the user.

MVC is considered a general solution to the problem of user control over large and complex data sets. The hardest part is typing names for the different building elements. Model-view-editor is the first set. They are described in the first note dated May 12, 1979: Thing-Model-view-Editor — an example of system planning.

After a long discussion, especially with Adele Goldberg, I finally used the term “model-view-controller” that I described in my second note of December 10, 1979: Model-view-controllers (Model-View-Controllers)

After I left Xerox PARC, Jim Althoff and others implemented an MVC version for the Small.-80 class library; I had no part in the work.

Oslo, February 12, 2007 Trygve Reenskaug

THING-MODEL-VIEW-EDITOR

An example of a planning system

Date: May 12, 1979 written by: Trygve Reenskaug to: LRG filed under: [IVY]SMALL> termin0logy2.doc

The purpose of this article is to explore the thing-model-view-editor structure through a coherent set of examples. These examples are drawn from my planning system and illustrate the above four concepts. All examples are implemented, although there are differences from the proposed architecture. This structure is corresponding to world-model-view-tool proposed by DynaBook in ([Ivy] Dynabook.doc).

THING

define

Something the user is interested in. It can be concrete, like a house or an integrated circuit. It can also be abstract, like a new idea or an idea about a paper. It can be a whole, like a computer, or it can be a component, like a circuit element.

Example: A large project

Suppose Thing is a big project. It could be the design and construction of a bridge, a power station or an offshore oil production platform. Such projects represent complex tasks with many interdependent details. The person responsible for the project must examine all details and dependencies in order to extrapolate the consequences of various possible actual or suggested scenarios. A number of different abstractions are used to help control large projects. Each abstraction highlights specific aspects of the overall project and is used independently or in conjunction with other abstractions to control these aspects. Abstract examples are reflections on material requirements, cost estimates, various budgeting and accounting theories. Activity diagrams (or flowcharts) or PERT diagrams can be very helpful in abstracting processes. They help us figure out what to do, who to do it, and when to do it. In an abstract network, each task that must be performed in a project is mapped to a simple element called an activity. Basically, an activity contains both its duration and its precursors. The duration refers to the time required to perform the corresponding task, while the lead is the activity that must be completed before the current activity can be started. This simple abstraction is usually extended in some way. Based on the precursors of activities, it is easy to find successors to each activity. The network starts with activities without precursors, and ends with activities without successors. Additional information can be attached to each activity. For example, the resource requirements of the activity, as well as the costs and cash flows associated with the activity.

MODEL

define

The Model expresses the abstractions (above) in the form of data in the computing system.

To discuss

As mentioned above, there are often many different ways of abstracting the same Thing, so it is often useful to have several coexistence models for the setup of a given “Thing”. Alternatively, one can think of the project as having one large Model, which is subdivided into several sub-models.

A model is represented in a computer as a collection of data and the methods needed to process that data. Ideally, all models should be exactly the same. This ideal is unattainable in practice; it will require great uniformity and stifling rigidity. Therefore, one should accept some inconsistencies, with the goal that the entire set of models should be a reasonable and accurate representation of the project without spending too much effort on trivia. In our example, the given NetworkModel is represented in a Smalltalk system as an instance of the class NetworkModel. Each activity in NetworkModel is represented as an instance of this class. One of the fields defined for the class NetworkModel is Activities — activity name (UniqueString) and a dictionary of activity instances. Three of the fields defined by the Activity class are Network, Established and successors. Network contains a pointer to the relevant instance of NetworkModel, and Establishes and successors are pointer vectors of Activity instance.

Ps: This can be understood in terms of something like a bidirectional linked list

The overall structure of our model (a representation of a network model for the Smalltalk project) is as follows:

In this generic framework, we can now add information about our project that can be linked to all networks and their Activities. For a network, we can add fields, such as plannedStart and plannedFinish. For the Activity class definition, we can add the fields Duration, earlyStart, lateStart, and resourccRcquirements. We could also add the field lateFinish for lateStart, but consider whether you really need it before you decide. (whether duration, earlyStart, or lateStart). Note that each activity’s Network Model and its child Models contain no information about how to display information on the screen, which keeps the project’s abstract Model clean.

VIEW

define

For any given Model, attach one or more views, each of which can display one or more graphical representations of the Model on screen. A View can do the same for models that are reasonably associated with the View (presenting data).

To discuss

If you follow the form-path-image (source-transform-display) principle, all View implementations will be simplified.

EXAMPLE 1: List of networks

A View belongs to a super-network, which is a collection of networks. Thus, it is slightly outside the scope of the Model currently under discussion, but is included in the completeness. The figure above shows what the network list looks like.

The Network list is an instance of the Class NetworkList, which is a subclass of ListView.

The ListView has fields such as frame, itemsList, and selectionItem. It can display its itemsList on a screen within its Frame and react to messages requesting scrolling. It can respond to click events within its frame range, as well as events that select an item.

Thus, the ListView is somewhat similar to the ListPane in the current system, but it is not a subclass of Window and cannot be scheduled. Therefore, it must rely on an Editor (a Controller variant) to tell it where its frame is and to schedule scrolling. One possible flow option is for the Editor to respond to the input and pass the position to the ListView. Then ask the ListView(or other View) to select the corresponding item. Separating the user interface from the data processing gives the Editor a great deal of flexibility. The Class NetworkList is built on ListView. This list is a network list, and it must know how to hold such a list. In addition, it must be able to execute commands that might be associated with the View. We consider only two such commands: return the name of the selected network and set (edit) the selected network.

EXAMPLE 2: The list of activities in a network

The list of activities in a network is an instance of the class ActivityList, which is a subclass of ListView (see the description of this general class above). An instance of ActivityList must at least know which network it belongs to and how to get a list of all activities in that network. There are no special commands other than the general selection mechanism provided by ListView.

EXAMPLE 3: Display the activity property

This is a text rendering of all the properties of an activity. It is an instance of the ActivityText class, which is a subclass of TextView. The TextView class has fields that can remember its frame and paragraph text. It can display text within a box via wrap-around and respond to messages that scroll text. It also has the ability to link a given coordinate to a position within a text and select text between a given position. Further, it can be asked to respond to messages based on various selected operations such as replace, cut, paste, and so on. So the class TextView is similar to current ParagraphEditor(ParagraphEditor), but each direct user interface is transformed into one or more messages so that it can work with other views through Editor and a variety of different editors. The ActivityText class must know how to get text for a given activity. This operation can effectively be triggered by a selection message, usually from the Editor. It must also be able to respond to messages about the activity that the user initiates through the Editor. A set of such messages is used to modify the data presented in the View, which is handled by the parent class TextView. Probably the most important command for ActivityText itself is to ask the View to check its current content and pass the data to the Network Model as an update to the activity’s properties. If this View inherits from the table View(listView?) Instead of being based on the text currently running, this View can be greatly improved.

EXAMPLE 4: Network Diagram

The diagram above is an instance of the DiagramView class. This is the only example where the data in the View cannot be completely derived from its Model, and it must have fields containing the shapes and positions of all the nodes, because that information is not part of the Model itself. Programs exist for automatically locating nodes in a diagram, but we assume that at least some manual editing is required. The position of the arrows can be inferred from the dependencies between activities, and this information can be retrieved from The NetworkModel when it needs to be displayed. However, such a process would be very slow, and for efficiency reasons, we assume that the DiagramView keeps a copy of this information. Like all other views, the DiagramView will need to provide the two actions needed to select an activity and the actions needed to scroll (this time in two dimensions). In addition, it needs to perform some operations on the View itself, which are related to the positioning of nodes in the View. Other operations must be associated with the NetworkModel, such as modifying an activity’s dependencies and passing the activity from one network to another.

EXAMPLE 5: A change in the Network Diagram

This View provides an alternative to the previous example. The nodes are smaller, allowing a larger portion of the network to appear on the screen. Small nodes make it impractical to display the activity name in the node, so the user must obtain that information in other ways. This network diagram is presented against a grid background. This is used when the user lays out the diagram, and the dot defines the allowed position of the activity node. This View can be implemented as a subclass of DiagramView, or both can be subclasses of some common View. However, in this implementation, two views can be generated alternately from the same object: The DiagramView class contains the field displayType, which has a value of # Large or #small, and the display is controlled by this field and displayed in the diagram in its own way.

EXAMPLE 6: Gantt chart

This View contains activity on the vertical axis and time on the horizontal axis. In this particular View, each activity corresponds to a timeline. By changing the shadows, you can easily control the progress of each activity without disrupting the entire project. Above is an example of the GanttView class, which is a subclass of ChartView. ChartView contains the background of the diagram: axes with legends, grids, and so on. It does not contain the information to put into the chart, in this case the horizontal bar. However, it helps its subclasses render this information by providing a means of converting from any coordinate system used externally to the frame coordinates of the graph. The GanttView class handles some of the user’s messages, most commonly those given through the Editor. For example, viewNetwork:, which provides the name of the current NetworkModel. It can also return the activity that the selected location belongs to and select the progress bar that belongs to a given activity. It can also deliver actions on its associated Network and Activitie, typically related to modifying the current schedule. Actions should be provided to plan networks (backload: and frontLoad:), modify the progress of individual activities (plannedStart: and planncdFinish:), and have the results of such changes executed correctly. NetworkModel must be able to handle operations such as pulling a list of all Activities from GanttPane. A network contains an overall schedule, and each activity has its own progress.

EXAMPLE 7: Resource map

The figure shows the time function of activitie’s sum of resource requirements. (Typically, each resource type will have one of these diagrams.) The diagram is an instance of the Class ResourceView, which is another subclass of DiagramView. The properties of gantt charts also apply to this point, but the concept of choice needs to be elaborated. This view needs to be able to return all activities that need resources on the X coordinate of all target points, and also need to respond to the message that *** selects *** : The activity can highlight the resource requirements it needs. Instead, it is best to combine the two and set multiple selection switches in all NetworkModel Views.

The EDITOR (the CONTROLLER)

define

Editor is the interface between the View and Model. It provides the user with an appropriate command system, such as the form of a menu, that can be dynamically changed based on the current context. It provides the View with the necessary coordination and command messages.

To discuss

Users can often View multiple views on the screen at the same time to better perform tasks. Users will want to manipulate these views by clicking, menu selection, or other means. Commands like select usually work with multiple Views at the same time. The purpose of the Editor is to create and locate a given set of views on the screen, coordinate them, and provide the user with an appropriate command interface.

EXAMPLE 8: UserView workspace

This is a very general purpose Editor that provides a user interface for any part of a running Smal1talk system that can be accessed from global variables. Therefore, it can be used as an interface to plan the view of the system, but it leaves most of the work to the user.

Because this Editor is always available, it is used to launch the more specialized Editor and execute the less frequently used commands to ensure this Editor. An example of the latter is a command to log out of a full database.

EXAMPLE 9: A fictional planning Editor

This Editor is very similar to the previous Editor, but it is created in the network. Therefore, messages for the network and all of its activities can be typed and executed directly through methods. Therefore, the complete content of the network and activity can be obtained from this Editor. This Editor is not implemented here, but is part of the larger Editor shown in the next example.

EXAMPLE 10: Nesting of the Editor

This Editor is part of the larger Editor (see the next example) and is designed to work within its context. (It’s actually the same Editor as example 9, scroll to the top of it). Editor is an instance of the DemoEditor class, a subclass of TextEditor. Therefore, regular text can be typed, stored, and edited in this Editor. In addition, because DemoEditor contains Network and all of its Activities, any messages supported by these objects can be entered and executed through methods. Because this Editor is part of a larger Editor (see the next example), we can perform more general actions, such as the activity duration, where the activity is interpreted as the currently selected activity. A variant of this subeditor can communicate with an instance of the ListView subclass to limit the user’s ability to execute predefined commands by disallowing any editing of the displayed text.

EXAMPLE 11: An EXAMPLE Editor

The Editor shown above demonstrates that a given Model can be displayed through different views. This Editor is an instance of the DemoEditor class, which is a subclass of PanedWindow. Each of its components is a child Editor that communicates with a particular View and sends and receives commands to the parent Editor.

Trygve Reenskaug Date: December 10, 1979

MODELS – VIEWS – CONTROLLERS

MODELS

Model stands for cognition. Model can be a single object (a single object) or some structure of an object. On the one hand, there should be a one-to-one correspondence between the Model and its parts, and on the other, there should be a one-to-one correspondence between the Model and the real world. Therefore, the nodes of the Model should represent the identifiable parts of the problem. Model nodes should all be at the same problem level, and mapping problem-oriented nodes (such as schedules) to implementation details (such as paragraphs) is confusing and considered bad form.

VIEWS

The View is a (visual) representation of its Model. It usually highlights some attributes of the Model and hides others. Therefore, it acts as a display filter. The View is attached to its Model (or part of the Model) and gets the data needed for the display from the Model. It can also update the Model by sending appropriate messages. All of these fetch methods and messages must be in the definition of the Model, so the View must know the definition of the properties of the Model it represents. (It’s quite possible, for example, that it could get an identifier for Model or an instance of Text, and it might not assume that Model is a subclass of Text.)

CONTROLLERS

The Controller is the link between the user and the system. It provides input to the user to arrange the relevant View to be displayed in the appropriate place on the screen. It provides the means for user output by presenting the user with menus or other means of providing commands and data. The Controller takes such user output, converts it into appropriate messages, and passes those messages to one or more views. The Controller should not complement the View, for example, by drawing arrows between nodes to connect the View of nodes (PS: the connection lines between nodes in the previous example should not be drawn by the Controller). In contrast, the View should not know about user input, such as mouse actions and keystrokes. You should write a method in the Controller that sends a message to a View that accurately reproduces any order of user commands.

EDITORS

The Controller is connected to all its views, which are called parts of the Controller. Some views provide a special Controller: an Editor, which allows the user to modify the information provided by the View. Such an Editor can be concatenated as a path between the Controller and its View, and will act as an extension to the Controller. Once the editing process is complete, the Editor is removed from the path and discarded. Notice that the Editor communicates with the user through an instance of the connected View, so the Editor is closely associated with the View. A Controller gets its View by requesting edits — there is no other suitable source.