IMPLEMENTING THE MODEL-VIEW-CONTROLLER PARADIGM IN ADA 95
Jodene M. Sasine
TRW Systems Integration Group
One Space Park
Building R5 Room 1121
Redondo Beach, CA 90278
Raymond J. Toal
Department of Computer Science
Loyola Marymount University
7101 West 80th Street
Los Angeles, CA 90045-2699
Abstract
The Model-View-Controller (MVC) paradigm was developed in conjunction with the Smalltalk programming language to provide the programmer a semi-automated means to create graphical user interfaces for Smalltalk applications. This paper presents the implementation of an MVC framework using Ada 95. Features of our implementation include an extensible architecture for supporting new platforms, event-driven behavior, and a novel registration-based broadcast notification mechanism. We show how several of the new Ada 95 language features are used to build the framework. In addition, we compare at length the differences between the classical Smalltalk MVC implementation and our Ada 95 implementation, and find that the Ada framework offers the application developer a number of advantages.
1.Introduction
The Model-View-Controller (MVC) paradigm is an established technology that is widely supported by industry. It was developed in conjunction with the Smalltalk programming language and environment [GR83]. The paradigm was designed to assist in the development of graphical user interfaces and to promote software reusability through object sharing.
Ada 95 [ISO95] is an internationally standardized object-oriented language designed to support the construction of very large, long-lived, reliable software systems. It differs from Smalltalk in that it is strongly typed and supports concurrency with language features rather than through library classes. The purpose of this paper is to show how Ada 95 can support the MVC paradigm by designing a framework for MVC applications written in Ada. The design is reviewed and a number of conclusions are presented concerning its feasibility. Comparisons are made between this design and the classical Smalltalk approach and it is shown that the Ada approach offers several advantages.
The objective of the work described here is to demonstrate the effectiveness of an MVC implementation in Ada 95 and to provide a simple case study for examining the development of object-oriented systems in the language. In particular, the successful implementation of the MVC paradigm in Ada testifies to the power and generality of the language, as we are able to elegantly express (in Ada) a paradigm which evolved in, and influenced the design of, a language very different from Ada.
This research makes three contributions to the area of MVC application design. First, we construct an Ada 95 hierarchical library to provide a framework for MVC applications. The use of a library, which is a physical system construct, helps to organize the collection of logical classes which often proliferate and clutter namespaces in other object-oriented languages. Second, we cleanly separate the graphical and non-graphical aspects of the MVC paradigm, allowing the use of bindings to interface to an external windowing environment. Our architecture allows new bindings to easily be inserted in a systematic way so that multiple platforms can be supported. Finally, a flexible broadcast notification mechanism is designed which reduces the implicit flow of messages in order to increase the understandability of the application. The mechanism also enables event-driven processing to replace the polling inherent in the classical Smalltalk implementation.
The rest of the paper is organized as follows. Section2 reviews the fundamental ideas of the MVC paradigm and its realization in Smalltalk. In Section3 we address the issues involved in implementing this paradigm in Ada due to the differences between Ada and Smalltalk. Section4 presents our approach to these problems and describes our Ada MVC implementation. We also compare at length this implementation with the classical Smalltalk approach. In Section5 we summarize our work and suggest areas of future research motivated by the ability of Ada to cleanly express and implement a popular, existing object-oriented methodology.
2.Background
In this section we outline the basics of the MVC paradigm, sketch its realization in Smalltalk, and motivate the reasons for constructing an implementation of this paradigm in Ada.
2.1The MVC Paradigm
Smalltalk-80 and the Model-View-Controller paradigm were originally developed for the Dynabook project [Kay93], a portable personal information management tool envisioned by Alan Kay. The essential idea behind the MVC paradigm is that application details should be separated from user interface concerns, and that the user interface is best factored into presentation and interaction components. MVC provides the framework for building user interfaces in Smalltalk; in fact Smalltalk itself is used to implement the paradigm as the interactive programming environment for the language. The Smalltalk-80 System Browser [Gol83] serves as an example of the paradigm.
The MVC paradigm consists of three components: a model abstraction, a view abstraction, and a controller abstraction. The model represents the underlying application domain, and encapsulates implementation details of the application’s structure and behavior. The view represents the way in which the model is presented to a user; it manages a region of the display and keeps it consistent with the state of the model. Each view is associated with a single controller, which converts user events (such as mouse button clicks or spoken commands) into operations on the model and view.
Each view/controller pair is associated with a single model, but a model may own multiple view/controller pairs. When a model is changed, its dependent views and controllers must reflect that change: a message notifying the dependents of the change is broadcast by the model, allowing the dependents to update their own state.
The standard cycle of interaction (summarized from [KP88]) begins with the user performing an input action and the active controller notifying the model to change itself accordingly. The model changes its state as required and notifies its dependents that it has changed. Dependents can then inquire the model about its new state: views may update their display if necessary; controllers may change their method of interaction depending on the new state of the model. A model may perhaps broadcast sufficient information on its state change to its dependents, so that inquiries from the dependents regarding the new state are not necessary.
2.2MVC Implementation in Smalltalk
The three Smalltalk-80 abstract classes Model, View, and Controller serve to implement the generic behavior of the primary components of the MVC paradigm; numerous concrete subclasses provide the features of user interface functionality required by interactive applications. The following abstract classes are subclasses of Controller: NoController, whose instances can never be active, MouseMenuController, which includes behavior for handling popup menus activated by mouse button presses, and ScrollController, for scroll bars. The classes StandardSystemView and StandardSystemController are subclasses of View and MouseMenuController respectively.
Detailed examples of Smalltalk applications developed with the MVC paradigm can be found in [KP88, Gol90]. The simplest example is that of a Counter, modeled by a simple integer value:
Model subclass: #Counter
instanceVariableNames: 'value'
classVariableNames: ''
poolDictionaries: ''
category: 'Demo-Counter'
A view of the counter’s value in a window together with a controller that can perform increment and decrement operations on the model completes the example. The application is run by sending the message open to the counter’s view. When the user increments the counter the controller evaluates the expression
self model increment
sending the message increment to the counter model. The body of method increment is
increment
self value: value + 1
where value: is defined as
value: aNumber
value aNumber.
self changed
When the model sends itself the message changed, each dependent view implicitly performs its update: method. Since the counter model is so simple, there are no parameters attached to the changed message, so each dependent CounterView simply arranges to update itself by querying the model’s value (through its display method):
update: aParameter
"Simply redisplay everything."
self display
Goldberg’s paper [Gol90] illustrates five different view/controller pairs that can be attached to a counter, using both text and bar views of the value as well as text and graphical buttons. Krasner and Pope [KP88] show how to interact with the counter using popup menus.
It is important to note that the association of multiple “dependent” view/controller pairs on a model, and the mechanism of change notification, are not implemented by the MVC components but are actually primitive abstractions in Smalltalk itself. In Smalltalk any object can have dependents: the protocol for the universal base classObject provides for having dependents and broadcasting messages to them. Even the method changed (which broadcasts the message update) is part of the protocol of class Object. Therefore much of the machinery to implement MVC programming is pre-existing in Smalltalk, which is unlikely to be the case in other languages.
2.3Ada 95
An attempt to implement the MVC paradigm in Ada 95 is important for several reasons. First, Ada is directed toward a different community of users than is Smalltalk and is an international standard. It is a broad language that covers areas such as object-oriented programming, distributed programming, and systems programming. Second, it is a worthwhile exercise to see how Ada 95 can support an existing paradigm and determine which aspects of the paradigm are easy, and which are difficult, to implement in the new language. Third, we aim to discover how a strongly-typed language implements the MVC paradigm (which evolved under a weakly-typed language). Finally, it is also worthwhile to determine how other powerful mechanisms of Ada, such as the hierarchical library, language-supported concurrency, and foreign-language interfacing, facilitate the implementation.
3.Ada MVC Design Requirements and Issues
In this section we summarize the basic requirements for an Ada 95 implementation of the MVC paradigm. We start with a general requirements summary and then discuss areas in which the differences between Ada and Smalltalk necessitate a new approach to implementing particular aspects of the paradigm.
3.1General Requirements
The model abstraction manages application-specific data. It should supply interface routines to its dependents for accessing its state, as well as routines to update the state in a controlled manner. The view abstraction must support the generic behavior of views in the system. A view must provide links between itself and a model and a controller, and provide for the initialization of a default controller. The view is responsible for displaying the model’s data. In graphical applications, a view may contain its own logical coordinate system so transformations to the display coordinate system must be provided (or made accessible to the view). The view must also respond to change notification from a model and query the model for state change information. The view must determine whether or not it needs to update itself.
A view can consist of one superview and zero or more subviews. The view must then provide links to its superview and subview(s) and manage (add to and remove from) its set of subviews. The controller abstraction must coordinate the model and views with the input devices and handle the scheduling of views; a controller must therefore provide links to its corresponding model and view and also to the input devices. The default scheduling policy provided by the controller assumes that only one controller at a time can interpret user actions,[1] so a controller must have the ability to determine whether or not it is in control (active). Only if the controller is active should it process user interactions.
Additional MVC requirements that should be satisfied in practice include standard “window system” processing for the view and controller classes, such as providing labels for active top-level views, manipulation of display attributes and the handling of popup menus. Many of these requirements are met by the Smalltalk-80 classes StandardSystemView and StandardSystemController. Window manipulation in Ada must be satisfied by bindings to a windowing system since window management is neither part of the Ada core language, its standard libraries, or its annexes.
3.2Ada Issues
An Ada MVC implementation is likely to have a different look, if not feel, from the Smalltalk implementation due to fundamental differences between the two languages. Issues which directly influence the development of the Ada framework are compile-time type checking, concurrency, interrupt handling, modularity, and bindings.
3.2.1Strong Typing
A language is strongly typed if no type errors surface at run-time; in object-oriented terminology this means that a message can never be sent to an object that has no method to handle it.[2] Strongly typed languages feature association of types with identifiers in source code and provide for compile-time type checking: this enhances readability, safety, and (often) performance. For example, an MVC implementation requires a View to maintain a set of subviews; strong typing assures that onlyView objects can appear in this set, removing a source of possible run-time errors. While not essential to object-orientation, several object-oriented languages have adopted strong typing, including Modula-3 [Nel91], Eiffel [Mey91], and Trellis [Kil92], as well as Ada.
It is very interesting to examine the issue of strong vs. weak typing when trying to mimic Smalltalk’s broadcast mechanism in a strongly typed language. Smalltalk’s broadcast mechanism makes essential use of weak typing in two respects. First, the dependents of an object may belong to different classes and respond to the broadcasted message in completely unrelated ways. The broadcasting object sends to each of its dependents the name of an operation that the dependent should perform (i.e., the name of a method it should invoke):
broadcast: aSymbol
self dependents do:
[:dependent | dependent perform: aSymbol]
For example, an object may initialize each of its dependents with the expression
broadcast: #initialize
The Smalltalk system consults a method dictionary at run-time for each dependent to find the appropriate body; run-time errors are possible since a dependent might not “understand” the broadcasted message. One might think that broadcasting operations in a strongly typed language involves passing a pointer to a subprogram, but it is unlikely that all dependents will want to execute the same subprogram! A strongly typed language that supports dispatching operations could arrange for the parent object to simply invoke the dependents’ operations.[3] Alternatively, each dependent can store its own desired response to an announcement from the parent.
Second, Smalltalk also takes advantage of weak typing in broadcasting non-unary messages. The messages broadcast:with: and broadcast:with:with: (as well as changed:with: and changed:with:with:) broadcast not only the operation to invoke but also the arguments to be used with the implicitly invoked methods. These arguments can be of any type, and since Smalltalk provides for heterogeneous arrays, there can be essentially any number of arbitrarily typed arguments broadcast.[4] A strongly-typed MVC implementation must retain this flexibility.
3.2.2Concurrency
Because Ada is a concurrent programming language, it is important that applications enforce mutual exclusion during updates to models and views. This can be handled automatically by the framework itself using Ada protected objects [ISO95, Ch. 9.4] in conjunction with creation and finalization. An interesting problem is that models and views are likely to participate in inheritance hierarchies and should be tagged types; however, protected types can not directly be tagged. One solution is to provide models and views with protected components whose management is transparent to the user. Another is to define a basic model or view as a protected object with a class-wide access discriminant [Int95, Section 9.6.1].
3.2.3Interrupt Handling
Classic Smalltalk MVC controllers follow a polling protocol; Shan [Sha89] has shown an alternate event-driven MVC framework. An Ada controller can make use of interrupt handling support from the Systems Programming Annex, or, if this annex is unsupported, the (obsolescent) Interrupt Entries feature. One can also use event-driven mechanisms of the environment. For example, a controller used in an X Window System application can enter an infinite X-Event loop.
3.2.4Modularity
One of the great strengths of Ada for software engineering is that the physical[5] structure of a program can be represented directly in the source text, as opposed to being left to a non-standard program development environment. The Ada 95 hierarchical library is a powerful tool for developing large software systems; we find it here to be an excellent mechanism for packaging frameworks. In this work, the various types and operations implementing the MVC paradigm are defined within a number of packages all rooted at the package MVC. This gives users the appearance of a single library, enhancing the usability of the framework by keeping its implementation manageable and preventing namespace pollution.
3.2.5Bindings
Another strong point of Ada 95 is its ability to interface to code written in other languages. This is particularly important in the domain of GUIs in which large libraries of foreign, often C, code exist (such as Xlib [Nye92] and the X Toolkit [NO’R93]). An Ada MVC framework can access these systems using pragmas Import and Export and facilities of the Interfaces Annex. Thus, Ada MVC applications should be easier to port across different platforms (X, Windows NT, OS/2) than Smalltalk applications, which are usually developed and run exclusively under the Smalltalk environment.
4.Ada MVC Implementation
This section details our construction of an Ada 95 MVC framework. The framework is presented as a hierarchical library which cleanly packages all components of the MVC paradigm and facilitates the job of the developer in creating an application. The library is organized along the following lines:
MVC
Support
Sets
Events
Core
Implementations
Motif
Standard_Motif_Views
Standard_Motif_Controllers
OS2