View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Designing good CRC cards - Charmant Kai Tan

When designing CRC cards, you want to do them good, so later on you'll be able to understand what it is you are trying to code and how. Here is the basics in designing good CRC cards.

Objectives

After completing this tutorial, you will be able to:
Think in an Object Oriented manor.
Use a responsibility-driven approach to object oriented development.
Run a CRC card session.
Use CRC cards of analysis and design.
Before starting this tutorial, you should:

Be an entity capable of intelligent thought.
Have some other entities, meeting requirement 1, with whom communication is possible.
Have a nice stack of 3 x 5 cards or something close.

Conceptual Overview

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 change 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. Even away from the office.
The 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 roll of that object...
The are a useful tool for teaching people 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.
Although CRC cards where created for teaching, they have proven useful for much more. They become an accepted method for analysis and design. The biggest contributing factor to there success is the fact that they provide an informal and non threatening environment that is productive to working and learning.

1. The CRC card session.

The Group

The ideal group size for a CRC card session is five or six people. This size generally allows everyone to productively participate. In groups of large size the productive is cut by more disagreements and the amount of participation by everyone is lower. If there are more than six people, one solution is to have the extra people be present strictly as observers.

The group five or six people in the core group should be composed of developers, domain experts, and an object-oriented technology facilitator. 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 Cards

The cards should look something like this:
CRCCard.GIF


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.

The Session

Before starting a session there needs to be some kinds of requirements for the systems. Weather they are implicitly or explicitly define the people participating in the group need to be familiar with them. A session also needs to focus on one part of the problem at a time. So a subset of the problem needs to be chosen to explored during the CRC card session.

Creating class

The first step in modeling an 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 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 obvious. The advantage of finding some in the beginning is that it help provide a starting place.
Superclasses and Subclasses

Superclasses and subclasses can be defined at any time they become obvious. The scenarios will illuminate these as well. It is up to the group to decided if they want to define any hierarchical relationships now or wait till the scenarios to do this.
Attributes

Attributes of class don't really need to be defined any time soon. They are an implementation detail. The responsibilities of the class will help make these clear. Attributes are general not defined at all till the design phase, but they can be defined at anytime the group thinks it is appropriate. Remember these are implementation details and should go on the back of the card.
Scenario execution

These are the heart of the CRC card session. Scenarios are walk-throughs of the functions of the system in detail. Take required functionality from the requirements document and use this as a scenarios. Start with scenarios that are part of the systems normal operation first, and then exceptional scenarios, like error recover, later.
First decide which class is responsible for this function. The owner of the class then picks up his card. When a card is in the air it is an object and can do things. The own announces that he needs to fulfill his responsibility. The responsibility is refined in to smaller tasks if possible. These smaller tasks can be fulfilled be the object is appropriate or they can be fulfilled be interacting with other objects. If no other appropriate class exist, maybe you need to make one. This is the fundamental procedure of the scenario execution.

Lets move on the Analysis and try out first CRC card session.

2. 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.

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.

...(Design Constraints)...

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 lets try our first scenario, taken from the requirement that the system bust 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?"

More about Analysis

The strength of CRC cards for analysis.

Common Project Vocabulary -
Spread Domain Knowledge -
Making the Paradigm Shift -
Live Prototyping -
Identifying Holes in Requirements -
When is the analysis done, and time to move on to design? When all the different responsibilities are in place and the system has become stable. After all the normal behavior has been covered, exceptional behavior needs to be simulated. When you notice that the responsibilities are all in place to support the new scenarios, and there is little change to the cards, this is a sign the you are ready to start design.
Activity 2.

Now let do some more scenarios and try to stabilize our system. Try these:
"What happens when Johny Codewarrior returns the book Document, Your job depends on it two days late? He has no other item checked out and no acquired fines."

"What happens when Ivar Jacobson uses the search feature to look for the book Object-Oriented Software Engineering of which there are 2 copies available?"

"What happens when Grady Booch uses the search feature to look for the book Object-Oriented Analysis and Design with Application of which there is 1 copy available and the database is down?"

3. CRC cards for Design.

In the design phase, the concentration moves from what to how. In this phase developers replace some of the domain experts in the group, but there still should be one domain expert in the group.
Strength of CRC card for Design

Spreading Objet-Oriented Design Expertise
Design Reviews
Framework for Implementation
Informal Notation
Things to consider in Design

Target Environment
Language
Choice of supporting software components
Performance Requirements
Other - memory, security...
CRC Element at the Design Stage

Classes

Think about what class are need to make the system work. Do you need a List class to hold objects? Do you need class to handle exceptions? Do you need wrapper classes for other subsystems? New classes that are looked for in this part, are classes that support the implementation of the system.
Scenarios and Responsibilities

During the problem modeling in the analysis phase the distinction between class and object is blurry. Now think about the objects in your scenarios. Who create the objects? What happens when it is created and destroyed? What is the lifetime of the object vs. the lifetime of the information held be the object?
Attributes

Now is the time to look at what information the objects hold compared to what is requested from other classes or computed of the fly. Use the back of the card to record the attributes found for the classes.
New things to record your cards

Subresponsibilities

Break you responsibilities into subresponsibilities and list the subresponsibilities indented under the main responsibilities. Move the collaborators next to the subresponsibilities that use them.
Collaborating Responsibilities

After the Collaborator class on your card list the responsibility of the used class that is used in the collaboration.
Data passed

After the collaborating responsibilities on your cards, list the data past back by the collaborating object in parenthesis.
Activity 3.

Redo the scenarios you did in the analysis phase, but know take in to consideration all of the design heuristics discussed. Make up your own scenarios and try them...

reference: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/

Links to this Page