Session 12

Implementation of MVC

810:171

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:

• The details of this code will be easier to understand if you first focus on the class hierarchy and on the inherited and overridden methods. Then try to trace the flow of the model values through to the views (1012323012).

• Isn't there an easier way?? This is too complex!!  --  Designers must make a trade-off between flexibility and complexity. In order to achieve flexibility, we decouple interfaces (view) from the data that they present (model). One of the side effects of decoupling is more indirection, which seems to be complex because you are not used to reading code based on indirection. But much real-world code is written this way! One way to minimize the confusion that comes with indirection is to try to understand the code from the top down -- from classes and relationships down to code details. Use what you know about MVC to help you read the code!!

• What does change() at the bottom of increment(), decrement(), and reset() do?  --  This is the model sending telling itself "I just changed!", in response to which it tells all of its dependents "I just changed!".

• For large systems, won't this be really complex and slow?  --  Complexity, we have already discussed above; it is the price we pay for flexibility. As for slowness, we must ask the questions, "How slow?" and "Is that too slow?" This way of achieving flexibility also charges a price in run-time speed, but in practice the cost is worth the flexibility available to development and long-term maintenance of code.

• Why did you use text files in your demo?  --  They are simple: easy to read and easy to write. Event-driven code is much harder to trace statically, because you can more easily simulate the state of the text file than you can a changing display.

  The more likely use of MVC is in an event-driven, distributed environment. If you would like to see such an implementation of MVC, check out the Java GUI version I provide on the code page.

• What is this, and why does view::view pass it to the model with its add_dependent message?  --  this is a pointer(C++)/reference(Java) to the object sending the message. In this case, the sender is a View, actually a CounterBoxView or a CounterLineView. Why? So that the model knows who to send an update() to later when the model changes!

• What does virtual = 0 (C++) or abstract (Java) mean?  --  These constructs are C++'s and Java's way for a class to say "Instances of me must respond to this message, but I do not know how they will respond. So a subclass of me must implement this method." Models must respond to the message value() -- that is how views ask them what their current value is, after receiving an update() message -- but the Model class has no idea what data any particular model keeps track of. So subclasses of Model must be sure to implement value().

Exercise 18: Supporting Programmers who Develop MVC Applications

Goals

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

Tasks

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.

Results

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...