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.

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.