CRC Cards

 A simple object-oriented analysis technique that includes the users and developers in the analysis
process
 A CRC card is an index card with three parts:
o Class -- name goes at the top of the card
o Responsibilities -- as a list on the left side of the card
o Collaborators -- as a list on the right side of the card
 Here's the layout:

ClassName
Responsibility Collaborator
   
   
   
   


 Class
o Represents a type of object being modeled
o One card per class
 Responsibility
o Something that the class knows (keeps track of) or does
o These should be the high-level responsibilities. Not trying to list out all member functions here
o Example: class Mailbox in a voice mail system might have these responsibilities:
 keep new and saved messages
 manage the recorded greeting
 Collaborator
o Another class that the current class has to work with to complete its responsibilities
o Could be a class that has information we need
o Could be a class that helps perform a task
o Typically, we list a class as a collaborator if we (the current class) need to call upon it to help
complete our own responsibilities
o Example: To succcessfully keep new and saved messages, the Mailbox class has to send them to
a MessageQueue to be added and stored. So on the Mailbox card, we list MessageQueue as a
collaborator

A CRC Card Session

 CRC cards can be used as a brainstorming technique, for the purpose of:
o Identifying objects/classes
o Identifying what each object's purpose is (responsibilities)
o Discovering the dependencies and relationships between objects (collaborators
 A CRC card "session" involves users and developers:
o Domain experts/users -- intended users of the system, people who know the business being
modeled. Good to have a few of these
o Developer/Analyst -- should have a couple members of the development team. People who
understand OOP modeling and development processes
o Facilitator -- one person who keeps things on track and progressing forward
 The process is based on going through use cases (or specific scenarios built from use cases), and using
these to discover objects, responsibilities, and collaborators
 The general process:
o Start with a scenario (usually representing a normal course through a use case)
o Identify initial classes/objects and make cards for them (this is can often be done by picking out
the nouns)
o Going through a scenario helps identify responsibilities of a chosen object
o Identify collaborations between objects that have been created
o Sometimes, we'll identify a collaboration with a new object type that doesn't have a card yet --
this helps discover new classes
o When new classes are created, walk through scenarios again to discover any new responsibilities
and collaborators (it's an iterative process)
o More use cases/scenarios will yield more classes, responsibilities, and collaborators
 Finding responsibilities
o Look for verbs in the scenario descriptions. These often tell us what an object does
o Also ask what the class knows. This tells us what an object needs to store. Sometimes a primary
responsibility of a class is management of certain unique information
 Finding collaborators
o If a class has a responsibility that required it to get, or modify, information it doesn't have on its
own, it will need to collaborate with another class
o Most often, one class specifically initiates the collaboration
o Usually, the collaboration is a request for information or a request to do something
o The initiator's card should list the helper class as a collaborator
o In this case, the initiator class depends on the collaborator class to accomplish its tasks
A CRC cards is an index card that is use to represent the responsibilities of classes and the
interaction between the classes. CRC cards are an informal approach to object oriented modeling.
The cards are created through scenarios, based on the system requirements, that model the behavior
of the system. The name CRC comes from Class, Responsibilities, and Collaborators which the
creators found to be the essential dimensions of object oriented modeling.

CRC cards where introduced by Kent Beck and Ward Cunningham in there paper "A Laboratory
for Teaching Object-Oriented Thinking" 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.

Why uses CRC cards?

· They are portable... No computers are required so they can be used anywhere.

· They allow the (group) 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 roll of that object.

· They are a useful tool for teaching the object-oriented paradigm.

· They can be used as a methodology them selves or as a front end to a more formal methodology
such as Booch, Wirfs-Brock, Jacobson, etc

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.

Creating class

The first step in modeling a system in the object-oriented paradigm is to identify the class in the
problem domain. So this is the first step in a CRC card session. Using the problem statement or
requirements document, identify the classes that are obvious in the subset of the problem that is
going to be explored in this session. One useful tool is to find all of the nouns and verbs in the
problem statement. The nouns are a good key to what class are in the system, and the verbs show
what there responsibilities are going to be. Use this information for the basis of a brainstorming
session and identify all the class that you see. Remember in a brainstorming session there should be
no or little discussion of the ideas. Record them and filter the results after the brainstorming. After
the classes have been chosen pass out cards and assign the class to the member of the group. Each
person should be responsible for at least on class. They are the owner of that class for the session.
Each person records the name of their class on a card. One class per card.

Responsibilities
Once a reasonable set of classes have be assigned to the group, responsibilities can be added. Add
responsibilities that are obvious from the requirements or the name of the class. You don't need to
find them all or any. The scenarios will make them more obvio

CRC cards for analysis.

Analysis is the process of modeling what a system does, not how it does it. Lets start by modeling a
sample system using CRC cards.

Activity 1

Do a CRC analysis of Breakout.html (Found on B Ericson Intermediate Programming CD)

– What cards do you create?

– What are the responsibilities of each object?

– What other object does each object work with to accomplish these responsibilities?

Activity 2

Problem statement.

This application will support the operations of a technical library for an R&D organization. This
includes the searching for and lending of technical library materials, including books, videos, and
technical journals. Users will enter their company ids in order to use the system; and they will enter
material ID numbers when checking out and returning items.

Each borrower can be lent up to five items. Each type of library item can be lent for a different
period of time (books 4 weeks, journals 2 weeks, videos 1 week). If returned after their due date,
the library user's organization will be charged a fine, based on the type of item ( books $1/day,
journals $3/day, videos $5/day).

Materials will be lent to employees with no overdue lendables, fewer than five articles out, and
total fines less than $100.

With this problem statement identify the class and assign them to the group members. Make a card
for each class.

Some ideas for class:

· application

· library

· material

· books

· videos
· journal

· company

· system

· ID numbers

· item

· borrower

· date

· organization

· employee

· article

· fine

This list is made up of the nouns in the problem statement. It is up to you to decide which ones if
any are good classes for this problem.

Now let’s try our first scenario, taken from the requirement that the system must allow users to
check out lendables.

"What happens when Johny Codewarrior, who has no accrued fines and one outstanding book, not
overdue, checks out a book entitle Document, Your job depends on it?"

Activity 3

• Do CRC cards for a bookstore website

• Do CRC cards for an ATM