Object-Oriented Analysis and Design 35511
to help the participants capture what they learn. At least one senior software architect
should be present, ideally someone with significant experience in object-oriented analy-
sis and design. In addition, you need to include at least one or two “domain experts” who
understand the system requirements and who can provide expert advice in how things
ought to work.
The most essential ingredient in a CRC session is the conspicuous absence of managers.
This is a creative, free-wheeling session that must be unencumbered by the need to
impress one’s boss. The goal here is to explore, to take risks, to tease out the responsibil-
ities of the classes, and to understand how they might interact with one another.
You begin the CRC session by assembling your group around a conference table, with a
small stack of 4×6 index cards. At the top of each CRC card, you write the name of a
single class. Draw a line down the center of the card and write Responsibilitieson the
left and Collaborationson the right.
Begin by filling out cards for the most important classes you’ve identified. For each card,
write a one-sentence or two-sentence definition on the back. You can also capture what
other class this class specializes if that is obvious at the time you’re working with the
CRC card. Just write Superclass:below the class name and fill in the name of the class
from which this class derives.
Focusing on Responsibilities The point of the CRC session is to identify the
responsibilitiesof each class. Pay little attention to the attributes, capturing only the most
essential and obvious attributes as you go. The important work is to identify the responsi-
bilities. If, in fulfilling a responsibility, the class must delegate work to another class, you
capture that information under collaborations.
As you progress, keep an eye on your list of responsibilities. If you run out of room on
your 4×6 card, it might make sense to wonder whether you’re asking this class to do too
much. Remember, each class should be responsible for one general area of work, and the
various responsibilities listed should be cohesive and coherent—that is, they should work
together to accomplish the overall responsibility of the class.
At this point, you do notwant to focus on relationships, nor do you want to worry about
the class interface or which methods will be public and which will be private. The focus
is only on understanding what each class does.
Anthropomorphic and Use-Case Driven The key feature of CRC cards is to make
them anthropomorphic—that is, you attribute humanlike qualities to each class. Here’s
how it works: After you have a preliminary set of classes, return to your CRC scenarios.
Divide the cards around the table arbitrarily, and walk through the scenario together. For
example, return to the following scenario: