The CRC Game

CRC Game

Overview

The Class Responsibility Collaborator (CRC) game identifies classes and responsibilities for an object-oriented software project. The game is played with a collection of standard index cards (3x5 or 4x6) that are divided into three sections, as depicted in Figure 1.

Figure 1

A class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities.

For example, in a university system, students are objects that students have names, addresses, and phone numbers. These are the things a student knows. Students also enroll in seminars, drop seminars, and request transcripts. These are the things a student does. The things a class knows and does constitute its responsibilities.

Students collaborate with other classes to fulfill their responsibilities. To enroll in a seminar a student needs to know if a spot is available and, if so, collaborates with the Seminar object to enroll in the seminar. Therefore, Seminar is included in the list of collaborators of Student.

Figure 2

Why use CRC cards?

• They are portable. No computer hardware or software is required and the game can be played anywhere.
• They allow the participants to tangibly experience the design of the project by physically playing the roll of an object.
• They are useful for teaching the object-oriented paradigm.

Game Strategy

The group size for a CRC session should be limited to five or six players. More than six tends to unnecessarily complicate the game with disagreements. Two kinds of participants should play every game: a domain expert whom understands the business domain and an object-oriented coordinator with experience in selecting meaningful class names.

Before beginning the game, the players should be familiar with the project requirements or problem description. The game is played in sessions that focus on one part of the problem at a time. Thus, a subset of the problem domain needs to be chosen that will be explored during the session such as a single requirement, user story, business rule, or system use case, instead of the entire collection of requirements.

1. Identify the classes.

One useful technique tool is to identify all of the nouns and verbs in the problem statement. The nouns define the classes in the system, and the verbs indicate their responsibilities. Use this information for the basis of a brainstorming session to identify all the classes that are obvious.

A good rule of thumb is that you should look for the three-to-four main classes right away, such as Student, Seminar, and Professor.

1. Determine the scenario

Execution scenarios are the heart of the CRC game and serve as detailed walk-throughs of the functions of the system. They are taken from the requirements document or problem statement. Start with scenarios that are part of the systems normal operation first, and then proceed to the exceptional scenarios and their recovery.

For the Student example above, enrolling in a class might be the first execution scenario to explore.

Add responsibilities

Once a set of reasonable classes have been identified, add responsibilities that are obvious from the requirements or the name of the class. All of them need not be found. The scenarios will make them more obvious. The advantage of finding some in the beginning is that it helps to provide a starting place.

Attributes are considered implementation details of the class and don’t need to be defined immediately but if they are, record them on the back of the CRC card.

Define the collaborators

Collaboration will be in one of two forms: a request for information and a request to perform a task. To identify the collaborators of a class for each responsibility ask, “Does the class have the ability to fulfill this responsibility?” If not, look for a class that either has the ability to fulfill the missing functionality or the class which should fulfill it. In doing so new responsibilities in other classes will be discovered as well as the need for new classes.

Playing the Game

First and foremost: There are no right and wrong ways for game play and scenario executions. Teams should make their own determinations on the game flow that works best for them.

Class Discovery

Begin with a brainstorming session to identify classes from the problem description and project requirements. Sometimes, this process consists of a person standing at a board writing the names of the classes as they are suggested by the players – or they could be recorded on a sheet of paper.

The classes are then examined more closely to identify obvious redundancies, related classes, etc. producing a filtered class list. Each player selects a class from the filtered class list and writes the name of the class on an index card with a short description on the back. These are the classes they will act out or “play”

Select three to four main classes and place them on the playing surface

Scenario execution

Select a scenario, such as “Enroll in a class” from the requirements and/or the problem statement and ask a question, like, “How does a student enroll in a class?”

Look for collaborating classes with responsibilities that fulfill the scenario – either on the surface or in the hands of the players. Two cards that collaborate with one another should be placed close together on the play area, whereas two cards that don’t collaborate should be placed far apart. Moreover, the tighter the collaboration, the closer they should be on the playing surface. Hierarchies of classes should be stacked on top of each other

Grouping cards that tightly collaborate makes it easier to understand the relationships between the classes.

If the scenario calls for a responsibility not already covered by one of the existing objects, the responsibility is either added to an existing class or a new class and card is created with the new responsibility.

If a card becomes too cluttered during play, rewrite the card to a new card seeking a more concise and richer description for the classes’ responsibilities. If it is not possible to compact the classes information and/or the class is already complex, create a new class to assume some of the responsibilities.

Players are encouraged to pick up the card whose role they are assuming while executing a scenario. It is not unusual to see a player with a card in each hand, waving them around, making a strong identification with the objects while describing their collaboration.

Clustering

After several scenarios have been executed a clustering pattern will likely emerge. Classes that seem to be doing too much work (or too little) can be reevaluated by the players for further refinement or additional class creation.

Additionally, refinements of an abstraction can be collected and handled as a single pile of cards with the highest level abstraction place on top where it can represent its concrete derivations.

Completing the game

The group should decide when enough sessions have been executed to produce a just good enough model. When accomplished, further modeling, if necessary, can be accomplished. References

A Laboratory For Teaching Object-Oriented Thinking. The original article by Kent Beck and Ward Cunningham.