Joseph Bergin

Typically CS1 focuses on programming. Analysis and Design (A/D) is often ignored in the CS curriculum except for the Software Engineering course. There is some evidence that this is inadequate. (Employer dissatisfaction with recent graduates' ability in this area.) The question is whether A/D can be taught to first year students, given the great number of other things that they must learn. I will leave the question of "should" for now, and assume that the answer to that question is at least a mild "yes," contingent on the question of "can."

One of the advantages of the OT (Object Technology) approach is that there is a smaller divide between A/D, on the one hand, and programming on the other. The tools and techniques are not as different as they are when standard structured methodologies are applied. This give us hope for an affirmative answer to the question at hand. Most OT practitioners recommend a spiral approach to development, in which a functional subsystem is delivered to users and used as the basis for further analysis, etc. The system grows through interaction between the users, designers, programmers, always with a growing, working system to use as a reference point. This avoids the problem that sometimes occurs with older technologies in which the system is finally delivered, complete, but after a long delay, and no longer meets the needs that have evolved in the interim.

There is also evidence from other educators that it may be possible to teach OOAD (Object-oriented analysis and design) to CS first year students. It is being done in a number of places and there was just recently (OOPSLA '96) a workshop on the topic. I did not attend this workshop, though I heard a postmortem on it, as will be detailed below.

Of course, we should not teach OOAD in complete detail in the first year. Nor do I think we need to adopt a sophisticated OOAD modeling tool for student use. In fact, figures drawn on paper is sufficient at this level, as is a general introduction to the topic, with enough detail to permit the students to develop simple designs.

Just as I believe that we should be teaching classes to students as soon as they are writing programs big enough to require more than one function, I believe that students should be introduced to OOAD at this same point. Students need to be able to design their programs --somehow--. They may as well learn a technique into which they can grow.

Note that there is an internet mailing list devoted to this topic. Participants exchange information on how/why to teach OOAD in the first year.

To prove the concept, I performed an experiment in my Java course. The students there are more sophisticated than first year students, of course, but had little if any background in OOP or OOAD. This technique was stolen "whole-cloth" from the OOPSLA workshop mentioned above. Workshop leaders were Rick Mercer, Robert Duvall, Mike Clancy, and Robert Biddle. This exercises is used by them with beginning students. I used slightly over an hour of class time on the following project. The actual materials used below are mine, as I did not have access to more than a brief description of their methodology. I'm sure that their materials are much better.

The problem as I stated it to my class follows.

Modeling a coffee machine

We want to design a coffee machine. A user can select different coffee products at different prices. The list of products is fairly extensive, such as decalf, espresso, and mocha. The machine maintains ingredients for each of the products. The user's choice is "made to order" from the ingredients. The products change from time to time, as do the prices, so it must be relatively easy to change these.

We want to design the interior working of the machine in an object-oriented way. Actually, all we need to design is a simulation of the machine. The simulation will then be used to control the physical devices. We do need an object "surrogate" for each physical device, however.

What objects are needed? How do they interact?

What messages (information flows) need to be implemented?

What classes are needed?

We used three techniques in the modeling-- Use-Case analysis (Jacobson, et. al.), CRC cards (Beck/Cunningham), and "Design by Walking Around" (explained below). I had given the students brief introductions to the first two of these previously. I have never before tried anything like the third method with a class. It felt extremely risky.

Use Case modeling examines the system from the viewpoint of a single user interacting with the proposed system in a single way. The prototypical use case is performing a cash withdrawal from an ATM. The next figure illustrates six different use cases performed by three different external actors on the ATM system.

A use case details the sequence of interactions that occurs. The analysis of a system consists of a set of use cases. The following is the beginning of the development of one of the use cases of the above figure.

The use cases are later used to verify the resulting system. Each use case is designed as a collection of interacting objects to carry out that case.

The same object may participate in many use cases. The total responsibilities of an object is the union of its responsibilities in all of the use cases in which it participates.

CRC cards are a way to detail the Classes, Responsibilities, and Collaborations of the objects in a system. Objects are instantiated from classes. They have responsibilities (see Use Case above). and they collaborate with other objects to fulfill a use case.

After going over the above problem with the class, we developed a single use case: purchasing a cup of java. I served as secretary and tried not to guide the discussion, other than to keep it going by asking questions.

USE CASE Buying a Cup-O-Java

When the customer selects a product, then the machine presents him/her with the required price.

When the customer deposits insufficient money, then the machine displays the remaining amount needed and also offers to let the user cancel the sale.

When the customer deposits sufficient money then the machine returns the required change, and mixes and dispenses the asked for product. It then determines what remaining ingredients are available and updates its menu of offerings accordingly, so that it can always dispense what the menu shows.

...

We then took a short break. Afterwards, we developed CRC cards for the system. Objects can be easily discovered by looking for nouns in the description of the problem an in the use cases. (Only a sampling of the information from six cards is shown below).

CRC cards

	CLASS		  Responsibility		Collaboration

	Menu			Show what is available	   Product List, Cash Box

				Interact with user

	Cash Box		Money calculations

	Change Maker		Dispense Change		   Cash Box

	Product List

	Ingredient (base class)

	Dispenser

	...

I then assigned each student in the class the ROLE of a single object as it interacts in the above use case. We had one Menu object, one Cash Box object, several Ingredient objects, etc. I played the role of customer (and kibitzer, of course). Students physically arranged themselves so that message passing would be simple. For example, the Change Maker stood near the Cash Box. We then carried out the use case by sending messages (talking) from object to object to object. I kept explaining that one of the major goals of design is to keep interfaces "thin" and information flows "small and simple". This simulation of the system in action reveals flaws in design and one can make adjustments to the class design and to the responsibilities of the objects during this exercise.

It was clear that the above was a FANTASTIC success. Several students congratulated me on it. (I had told them how risky it had felt to me earlier, and that it was the first time I had tried this method.) Students really got the message that objects are active and autonomous from this exercise. They also saw OOAD in action, but in a very simple and familiar context. While I used "Design by Walking Around" as a teaching tool, one of the students who is responsible for hiring/training programmers agreed that it could be used in his organization to actually do design. It really worked, and it took relatively little class time.

Bibliography

Kent Beck, Ward Cunningham, "A Laboratory for Teaching Object-Oriented Thinking", Proceedings of OOPSLA '89, ACM 1989

Grady Booch, Object Oriented Analysis and Design with Applications, 2ed, Benjamin Cummings 1994.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison Wesley, 1992.

James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, Object-Oriented Modeling and Design. Prentice Hall, 1991.

Rebecca Wirfs-Brock, B. Wilkerson, L. Wiener, Designing Object-Oriented Software, Prentice Hall, 1990.

NOTE: Use case figures are adapted from workshop notes of a Use Case Modeling workshop given at OOPSLA '95 by Magnus Christerson and Patrik Jonsson. The CRC figure is taken from "Data Abstraction: The Object-Oriented Approach Using C++," McGraw-Hill, 1994, by myself.