Session 12

Implementation of MVC


Software Systems

Recap Session 11: Considering How To Implement MVC in a Program

In Exercise 16, we studied a program that used a change propagation mechanism similar to MVC. A Reactor could watch other Reactors, so that when the "watched" changed the "watcher" could update itself (and propagate the change to any Reactor that was watching it). This change propagation mechanism is just what an MVC system requires--though Models and Views are different components, and so the elements of the mechanism will be distributed over them.

In Exercise 17, you are studying a simple implementation of MVC, in which the ideas of "watched" and "watcher" are separated into Model and View, respectively.

Summary from Exercise 17

Not all of you managed to digest this code very quickly. It is considerably more complex than the reactor demo, but some of what you see is similar. The "subscription" mechanism for dependents and change propagation has been factored into two classes, Model and View. The "core functionality" of the example resides in a class derived from Model, Counter. The interface components of the example reside in classes derived from View. (Our interface is file-driven, for the sake of simplicity and portability.)

Feel free to continue to study this code. Download it, compile it, and run it. Try to follow the inheritance relationships. Simulate the code's execution by hand. You will have a better feel for MVC if you understand this simple implementation example. Feel free to ask any questions you may have, next time in class, and we will try to answer them!

Here are some of the questions and issues raised by students in this and previous sections:

Exercise 18: Supporting Programmers who Develop MVC Applications


  1. To understand better how MVC works.
  2. To understand better the ways in which software tools can support programmers who develop user interfaces.


Work in the same teams as you did for Session 17.

You may want to consider dividing up the tasks to be done, working independently for a while, and then come to together as a group at the end of the session to discuss and refine your answers.

  1. Describe a specification method for MVC-based systems, and give a simple example. Consider each of the techniques discussed in Section 5.2 of Designing the User Interface.

  2. Describe an interface-building tool for MVC-based systems, and give a simple example. Consider each of the techniques discussed in Section 5.3 of Designing the User Interface.

  3. Describe an evaluation tool for MVC-based interfaces, and give a simple example. Consider the ideas discussed in Section 5.4 of Designing the User Interface.

For each task above, be sure to explain why the idea or technique you chose to use is a good choice for supporting MVC programmers.


Your group submits solutions to all three tasks.

We will discuss candidate solutions as a class.

Summary from Exercise 18

Applying the techniques you read about in Chapter 5 is a better way to learn their strengths and weaknesses than just staring at the pages. For example, a grammar for MVC developers probably isn't the most convenient tool for describing MVC systems. The important relations that exist in an MVC system seem to be more easily visualized than written in text. A transition diagram or state chart offer much more expressiveness. But the typical examples are low-loevel, and typically procedural.

Having a design tool like LabView for MVC seems to be a wonderful idea. Designers could create "pictures" of the models, views, controllers, and interactions and have a second pane show what the users would see. The tough part to implementing such a design tool is having provide useful feedback on the model, which lies underneath the surface of the user interface (the views).

What might an automated critic of MVC design say? What can it say, based only on code and design? Well, it could consider the relationship between views and models (does the model's interface support the designed views? what about potential views) and views and controllers (does the mode of interaction available to users match the way the view presents data?). We could also apply HCI principles to the views themselves and ADT/OO principles to the models themselves. Might a tool recognize an loop in the dependencies of views on models? Is that necessary?

One reason that this exercise is hard: it doesn't constrain you! Freedom can be daunting. But it also provides opportunities to try just about anything out, in the service of understanding the concepts being studied.

Another reason that this exercise is hard: you need to understand the material in Shneiderman's Chapter 5. Technical material can be daunting. But it also provides opportunities for you to explore those ideas, in a relatively forgiving environment...

Eugene Wallingford ==== ==== February 15, 2001