Appendix G. The CRC Card Methodology
A CRC card is ostensibly an index card that is used to represent
classes, their responsibilities, and the interactions between them.
The term CRC card is also used to refer to a methodology for object
oriented modeling based on their use.
Kent Beck and Ward Cunningham introduced CRC cards in a paper
"A Laboratory for Teaching Object-Oriented Thinking" that was presented at
the OOPSLA (Object-Oriented Programming, Systems, Languages & Applications)
conference in 1989.
A tutorial on the subject can be found at
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/.
The CRC card methodology was originally designed as a teaching tool but
has proved useful as a modeling tool as well.
The three parts of the CRC acronym were felt by the authors of the
paper to represent the essential dimensions of object oriented modeling.
The term Responsibilities refers to the contract that the class
under discussion offers to the rest of the world (Interface and
Contract are similar concepts).
Responsibilities model the things that a class can do.
Services, Methods, or Operations will result from these.
The term Collaborators refers to the classes whose services
the class under discussion will use.
Kent Beck tried unsuccessfully to use ther term Helpers instead of
Collaborators to indicate classes that were supporting the class under
discussion.
It is widely believed that the terminology was chosen because CRC are
the initials of Ward Cunningham's son.
Why use CRC cards?
They are portable.
No computers are required so they can be used anywhere.
Even away from the office.
They allow the participants to experience first hand
how the system will work.
No computer tool can replace the interaction that happens by
physically picking up the cards and playing the role of that object.
They are a useful tool for teaching people the object-oriented
paradigm.
They can be used as a methodology themselves or as a front end to a
more formal methodology such as Booch, Wirfs-Brock, Jacobson, etc.
Although CRC cards were created for teaching, they have proven
useful for much more.
They have become an accepted method for analysis and design.
The biggest contributing factor to their success is the fact that they
provide an informal and non threatening environment that is
productive to working and learning.
The exact format of the card can be customized to the preferences of
the group, but the minimal required information is the name of the
class, it's subclasses and superclasses, it's responsibilities
and the collaborators for each of those responsibilities.
The back of the card can be used for a description of the class.
During the design phase attributes of the class can be recorded on
the back as well.
One way to think of the card is that the front contains
the public information, and the back contains the encapsulated,
implementation details.
As a class is defined a card is made for that class with
its name entered.
When a class is assigned to an individual that has only a class name
on it, the individual (or the group) selects an initial set of
responsibilities for the class.
This initial set should be whatever (if anything) is
immediately obvious.
