CPS 108: Coffee Machine Design Problem

Spring 1999

Due at the end of class.

Form groups of size four or five persons. You may not work alone! You should start this group activity by introducing each member of the group. You may also want to choose one (or two) person(s) to write down the group's discussion as you go.

There are three parts to this activity:

Developing a design for a program to run an office coffee machine
Developing and writing down that design so that others can understand your design
Verifying your design works reasonably for a variety of test or "use" cases

What is "Design"?

If you have done an object-oriented design, how do you describe it to another person? What do you talk about or show, to convey your design? While your code is the ultimate resource to describe a design it is often not sufficient to convey your design accurately and quickly. Instead, you need a more concise way to present your design. A good design presentation will consist of the following things:

The name of the key components, or things, in the system.
The purpose, basic function, or main responsibility of each thing.
A drawing of the key communication paths between them.
A list of the services provided.

Of the four design elements, the brief "responsibility statement" is the most important. It tells an experienced person what will be included and what will be excluded from the data and behavior for the component. Then communication channel summaries show the collaborations between the things and the traffic patterns within the system. From this "map", purpose plus collaborations, an experienced person can reasonably find her way to interesting parts of your design.

For this exercise, you are going to use CRC cards to describe your design. A CRC card is a small piece of paper that lists the Class, its Responsibilities, and its Collaborators. The first describes its name and purpose (briefly). Next, its responsibilities (or methods). And finally, those classes that it collaborates with to complete its responsibilities. A single CRC card should be made for each class in your system.

The Coffee Machine Problem

You are a member of a group of contractors who just won a bid to design a custom coffee vending machine for the employees of Acme Fijet Works to use. Arnold, the owner of Acme Fijet Works, like the common software designer, eschews standard solutions. He wants his own, custom design. He is, however, a cheapskate. Arnold tells us he wants a simple machine. All he wants is a machine that serves coffee for 35 cents, with or without sugar and creamer. That's all. He expects us to be able to put this little machine together quickly and for little cost.

We get together and decide there will be a coin slot and coin return, coin return button, and four other buttons: black, white, black with sugar, white with sugar.

Now, design the machine using objects. What are the components, what are their responsibilities, how do they work together to deliver the simple service: give coffee for 35 cents?

Use Cases

Test your design against Kim's test scenarios.

Kim puts in a quarter and then selects a coffee.
Kim puts two quarters in and then selects a coffee.
Kim puts in a quarter, then pushes the coin return lever.
Kim puts in a two quarters, then walks away from the machine and forgets to come back.
Kim buys two coffees, white with sugar. The sugar dispenser runs out of sugar after the first.

For each of these scenarios, each person in the group should "be" one or more classes in your design. This means you should take the CRC card representing your card and try to act like that class should act during program execution. In playing this role, it is important to be extremely literal in your interpretation of the class' responsibilities. One good way to "get into character" is to pretend that your class is a company that is trying to be as profitable as possible. To be profitable, the company must be as accomodating as possible to its clients (collaborators) while at the same time doing as little as possible (i.e., delegating work to other companies (classes)).

When you have successfully completed a scenario to your group's satisfaction, draw the interactions of your classes on a separate piece of paper. Your diagram does not have to be fancy, but should show which class called what to complete the scenario.

While working through these scenarios, it may be helpful to keep the following questions in mind:

Which component knows the price of the drink?
Which component knows how to make the drink?