Session 9

Software as a Product


810:171

Software Systems


Exercise 13: Warranting Performance of Software

Goals

  1. To understand better the nature of software, especially its relationship with users and their expectations.

Tasks

Work in teams of three or four people based on the number in the upper right hand corner of this page.

  1. Make a list of the features for which a software producer can reasonably offer a warranty on system performance. Why can the producer offer a warranty on each feature, and why should the producer offer a warranty on each feature?

  2. For each feature, identify two or three actions that the producer can take to ensure that the software meets the warranty. Tie these actions to stages in the LUCID life cycle.

  3. What features should a software producer not warrant in its product? Why not?

At the End

  1. You argue your case in class.
  2. Your group submits its write-up.


Summary from Exercise 13

A year or so, the Waterloo/Cedar Falls Courier ran a series of articles about a case that came to mind when I prepared for today: a couple was charged with tax fraud, and one line of defense was that they relied on Quicken, a tax software package, and got confused. The jury was apparently unmoved by this argument, in light of the size of the error (five or six figures...). The result was jail time.

I developed this task after thinking about a complaint made in The Killer Robot Papers: LOOT made no warranty on the use of the SHEOL tool! Making warranty on how a user uses a tool seems pretty risky, beyond saying that within prescribed bounds of use the tool will function correctly. Then there is the famous story about the lawnmower, the disheveled hedge, and the two well-intentioned fellows who decided to give it a trim...

What is the purpose of a warranty? I would argue that a warranty is not a claim that the product will not break. For systems of any reasonable complexity, such a claim is unreasonable. As some of you pointed out, a warranty is more about customer satisfaction. It says, "Even if this product fails, we want you to be happy. So we will bear the cost of failure (or some part thereof) for some period of time." Now we are in a realm where software warranties make sense.

Many of you made the claim that software is different from other products, which is true, and that, as a result, software warranties are unreasonable. If your intent in making the warranty is to claim that the software will not break, you are right. If you take the broader view of warranties as a means to curry customer favor, then not offering a warranty of some sort is unreasonable.

Why do mechanical systems fail?
Why do software systems fail?

Keep in mind that computers and software are increasingly used by non-technical people who are not fazed by your claim that software is "different". My dad made cars for a living, and giving warranties is a standard part of the auto industry. It will take more than our strident claim that software is different to convince people like him that we shouldn't be doing more to ensure our customers' satisfaction.

Keep in mind that computers and software are increasingly used by non-technical people who are not fazed by your claim that software is "different". My dad made cars for a living, and giving warranties is a standard part of the auto industry. It will take more than our strident claim that software is different to convince people like him that we shouldn't be doing more to ensure our customers' satisfaction.

So, we software developers have a couple of tasks:

Some of the ideas that you offered in class as to how software is different: the environment in which software operates is complex, increasingly varied, and increasingly autonomous; the potential complexity (which means things we might not anticipate when developing the software) is much greater than for many systems. (But keep the lawn mower guys in mind!)

I overhead one group say, "Well, a program should do what it promises to do." What does a word processor, for example, promise to do? How do we know when it has delivered?

Software is different. So is building it.


Exercise 14: New Technologies in the Software Development Process

Goals

  1. To prepare for learning new technologies in this course and beyond.

Tasks

Work in the same teams as you did for Exercise 13.

Imagine that you are members of a software development team. Your supervisors have called a meeting at which they will introduce a new development technology and an associated set of support tools for use on your new project. How would you prepare for such a meeting? What questions would you be prepared to ask? What sort of support would you expect your company to provide?


A UI Design Pattern: Model-View Controller

(Note: I also used some slides to illustrate MVC in class. A couple of the diagrams in those slides may help you...)

Suppose that we wanted to implement a simple information system for political elections. In many countries, multiple parties compete for proportional representation in a legislative body. A spreadsheet would provide a nice user interface for entry and viewing of data. But other users may prefer or need other kinds of interface: pie charts, bar charts, seating views, etc. Users can interact with the data using any of these interfaces. All of the interfaces should provide a similar "look and feel" for consistency. New interfaces should require little if any change to the underlying data model.

Context

You are building an interactive application.

Problem

Programs that mix functionality with interface make it impossible to change one without changing the other.

Forces

This problem is really many problems rolled into one:

If the data model and the user interface(s) are interdependent, all of these problems become quite difficult to solve. An interface change will affect the data model implementation. A change in the data model will affect many or all of the interfaces.

These are some of the forces at play:

We want our domain-specific code to be about the domain data. This code should simulate objects or processes in the domain, which doesn't include displaying itself in n different ways on m different platforms.

What we don't want:

What we do want:

Solution

Create a different kind of object for each role in the user interface:

By separating the view from the model from the controller, we are able to make additions or changes to any one of the components independent of the other components.

If there are multiple views open on the same data model and the data change in some way (say, through user input), then all of the views should be updated immediately to reflect the change. In order for this to happen, the model must notify all views whenever its data changes. The view can then request any relevant data from the model and update its display.

The Change Mechanism

A view is created on a specific model. At creation time, the view sends a message to the model saying, in effect, "I am watching you." The model maintains a list of dependents, which are objects that care about the model's data. When it receives the "I am watching you" message from the view, it adds the view to its list of dependents.

Whenever the model changes one of its data values, it announces the change to all of its dependents. If the view cares about the aspect that has changed, then it asks for the data and and updates its display.

An important observation: At no time does the model send unsolicited information to the view. It only responds to a request. In fact, the model has no idea which views care about which of its aspects at all! It only has a list of dependents that it alerts when one of its data changes.


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