Session 10

Technology for UI Design


810:171

Software Systems


Recap Exercise 14: New Technologies in the S/W Development Process

In Exercise 13, we considered what it would mean for software developers to offer real warrabties on their products. We decided that warranties were about customer satisfaction, not about lack of defects--so warranties can and do make sense, though the nature of loss and relief might change in the context of software.

In Exercise 14, you are considering what you as a developer would want your employer to provide you as it came to expect you to use a new tool or technique as a part of developing software. This exercise bridges the stories we've read in The Case of the Killer Robot and the rest of the course, in which you will learn new tools and techniques for interface development. (We encounter the first of those in Exercise 15.)


Summary from Exercise 14

This exercise was motivated on two fronts. The first was the story in The Killer Robot Papers about how John Cramer introduced object-oriented software development and the SHEOL tool to the CX30 project. The developers of Robbie were steamrolled by a new paradigm. The second motivation came from your initial reading of Chapter 5. We are entering a phase in the course where you will be introduced to a number of new tools and techniques for software development, especially as it relates to human-computer interfaces. I'd like you to feel like you can encounter new ideas and not be steamrolled.

Many of you suggested that you would do some research on the new technology and tools prior to the meeting. (Please keep in mind, though, that the Internet is not necessarily the best place to do such research!!) Among the questions that you suggested were:

Among the support that you expected were:

I will point out that you may want to think about the time frame of the project... How long will training last? How long do we have to develop expertise with the ideas? One-week training sessions in "how to do object-oriented <x>" have done more damage to OO migration than anything else I can think of.


Exercise 15: Understanding Model-View-Controller

Goals

  1. To understand the Model-View-Controller pattern for user interface design.

Tasks

Work in the same teams as you did last time.

Base your work on your reading of the "Model View-Controller" paper and on the short presentation last session.

At the End

Your group submits its write-up and list of questions.

We will discuss your questions and try to provide answers.


Summary from the Exercise 15

Here are some typical questions students ask, with brief answers. If you have any questions that you didn't ask in class and that you don't see answered here, be sure to ask in person or e-mail soon!

What is a controller? It is the software component underneath the mechanism by which the user gives input to the system--a mouse, a keyboard, a stylus, or whatever. They are connected to a particular view. If you know some Java, a controller is a lot like a listener...

Several of the questions I asked involved the meaning of the class diagram on Page 129 and the interaction diagrams on Page 130-131.

The class diagram shows that the View class and the Controller class inherit from the Observer class which, along with the Model class, implements the generic change propagation mechanism. We don't want to have to implement this mechanism more than once, so we use subclassing to provide it to all applications.

(For those of you with Java experience: Java defines an Observable interface that can serve as the root for a set of observer classes. Controllers in MVC most closely correspond to the listeners that we define in the Java event model.)

The interaction diagrams show high-level traces of messages being sent among objects in a piece of an application execution. What may be confusing is that Scenario 2 will actually precede Scenario 1 in a run, since it shows how the instances of Model, View, and Controller (actually, instances of subclasses of these) initialize one another. Scenario 1 then shows what might happen when a controller responds to a user input.

Several of you discussed database systems as a possible application of MVC. One could implement a DB system using MVC, but typical DB systems are not implemented that way. Databases must deal with other critical issues such as record locking, and most implementors prefer to maintain more control in the DBMS as a way to simplify how these issues are handled. One could use MVC (which trades control for flexibility) but add extra control mechanisms to the model and its interaction with views.

Another possible application is a web browser. MVC would support auto-update when the displayed content changed! Of course, HTTP doesn't work that way.

A couple of examples of MVC that really are out there are the "publish-subscribe" mechanism that one sees in today's word processors and the "document-view" mechanism in teh Windows world.

A neat example of change propagation a la MVC is in spreadsheets, where cells are models, but also views on other cells... Think about it!


Eugene Wallingford ==== wallingf@cs.uni.edu ==== February 8, 2001