CRC cards were introduced by Kent Beck and Ward Cunningham in their paper &quot;A Laboratory for Teaching Object-Oriented Thinking&quot; released in OOPLSA '89. There original purpose was to teach programmers the object-oriented paradigm. When Kent Beck wrote the draft version of their paper he changed Collaborators to helpers. Ward Cunningham changed it back to Collaborators when he reviewed the paper. The initials of Cunningham's son are CRC.
Although CRC cards were created for teaching, they have proven useful for much more. They 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.
These are terms used throughout this tutorial as defined by Grady Booch.
This size generally allows everyone to productively participate. If there are more than six people, one solution is to have the extra people be present strictly as observers. In the initial Analysis phase there should be two or three domain experts, one object-oriented technology facilitator, and the rest of the group made up of people how are responsible for delivering the system. As the project moves more in to the design phase, some of the domain experts can be replaced with developers. There should always be at least one domain expert in the group to clarify an question that arise about the behavior of the system.
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 responsibilities and the collaborators. 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 the front as the public information, and the back as the encapsulated, implementation details. So you might list attributes (properties) on the back.
Remember, for larger projects, we won’t be looking at the entire problem. Only a portion.
Always start with basic functionality at first. Only move on to advanced or optional functionality later. Examples: Error checking, non-essential, and so on.
Resist the temptation to get too far into the details.
Portable... No computers need. 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 useful 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 USDP, RUP, Booch, Wirfs-Brock, or Jacobson.