Comparing Sequence and Collaboration Diagrams

In the late 1980s, one the biggest centers of object technology was the research labs of Tektronix, in Portland, Oregon. These labs had some of the main users of Smalltalk, and many key ideas in object technology were developed there. Two renowned Smalltalk programmers there were Ward Cunningham and Kent Beck.

Cunningham and Beck were and are concerned about how to teach the deep knowledge of Smalltalk they had gained. From this question of how to teach objects came the simple technique of Class-Responsibility-Collaboration (CRC) cards.

Rather than use diagrams to develop models, as most methodologists did, Ward represented classes on 4 6 index cards. And rather than indicate attributes and methods on the cards, he wrote responsibilities.

So what is a responsibility? It is really a high-level description of the purpose of the class. The idea is to try to get away from a description of bits of data and process and instead capture the purpose of the class in a few sentences. The choice of a card is deliberate. You are not allowed to write more than will fit on the card (see Figure 5-6).

Figure 5-6. Class-Responsibility-Collaboration (CRC) Card

The second C refers to collaborators. These represent the other classes that this class needs to work with. This gives you some idea of the links between classesstill at a high level.

One of the chief benefits of CRC cards is that they encourage animated discussion among the developers. When you are working through a use case to see how classes will implement it, the interaction diagrams in this chapter can be slow to draw. Usually you need to consider alternatives, and with diagrams, the alternatives take too long to draw and rub out. With CRC cards, you model the interaction by picking up the cards and moving them around. This allows you to quickly consider alternatives.

As you do this, you form ideas about responsibilities and write them on the cards. Thinking about responsibilities is important, because it gets you away from classes as dumb data holders and eases the team members toward understanding the higher-level behavior of each class. A responsibility may correspond to an operation, to an attribute, or (more likely) to an undetermined clump of attributes and operations.

A common mistake I see people make is generating long lists of low-level responsibilities. This is really missing the point. The responsibilities should easily fit on a card. I would question any card with more than three responsibilities. Ask yourself whether the class should be split or whether the responsibilities would be better stated by rolling them up into higher-level statements.

When to Use CRC Cards

Use CRC cards to help explore an interaction between classes, typically to show how a scenario is implemented. Once you've figured out how the interaction works, you can document it with interaction diagrams.

Use responsibilities to help you summarize the key responsibilities of a class. They are useful in highlighting cluttered classes.

Many people stress the importance of role-playing, where each person on the team plays the role of one or more classes. I've never seen Ward or Kent do that, and I find it gets in the way.

Where to Find Out More

Sadly, Cunningham and Beck have never written a book about CRC, but you can find their original paper (Beck and Cunningham 1989) on the Web (<http://c2.com/doc/oopsla89/paper.html>). On the whole, the book that best describes this techniqueand, indeed, the whole notion of using responsibilitiesis Wirfs-Brock (1990). It is a relatively old book by OO standards, but it has aged well.