How does one elaborate design using CRC cards?

Question

I've always been wondering how people use CRC (class responsiblity collaboration) cards. I've read about them in books, found vague information on the internet, but never grasped it really. I think someone ought to make a youtube video showing a session with CRC cards, since one of my books described it as being very hard to formulate in text, that it should be "taught by someone who already masters it". Sadly, I know noone around here who uses CRC cards and I'd like to learn more.

UPDATE

Any links to videos showing people elaborating with this technique would be appreciated.

Answer 1

I'll try to give an answer. So CRC cards are generally used for modelling in a Object-Oriented environment to get a better understanding of the system that has to be developed (but that I think you'll know already). CRC cards come at the very end, when you arrive just before the actual implementation. The different steps to reach that level could be the following:

1. The starting point is to do the requirement elicitation. Involving the customer early and continuously is suggested here (take a look at Agile approaches, i.e. Extreme Programming)
2. The requirements can then be modeled either with Use Case diagrams (UML) or with User stories (agile extreme programming approach). The key problem here is to find the right involved objects. This depends very much on the domain you're in, of course. If you go the "hard" way, you can apply techniques like "noun extraction". So you parse the specification document and extract all nouns (including composite names and those with adjectives). Analyze all of them and discard the irrelevant ones.
3. Once you have the right nouns -> objects you can start creating your CRC cards. So what is done in a CRC session? The main task is to find and assign the responsibilities of your (previously) found objects which are then put down on small index cards (our CRC cards). "Responsibilities" are mainly the core functionalities of a specific object and the "collaboration" part are the needed other objects for fulfilling certain functionalities (these are the dependencies among the different objects in your model). Important points for assigning the responsibilities is that the responsibilities are distributed well on the whole system in some kind of balanced way. Another very important point is to avoid any duplication of responsibilities among the objects (this is where the CRC cards help).
   A CRC session should start with a brainstorming meeting, having an active discussion among the developers and it should be performed on the actual index cards directly.

I hope I was able to somehow help you.

Regards,
Juri

Answer 2

It's hard to summarize in an SO answer, but I'll try. One of the challenges of designing objects is balancing thinking from an overall perspective with thinking from the perspective of an individual object. You need the overall perspective to get the computation completed, but you need the individual object perspective to effectively subdivide the logic and data.

Maintaining this balance is where CRC cards come in. When they are sitting there on the table, you get to look at the computation as a whole. When you pick up a single card, though, you are physically, kinesthetically encouraged to take the point of view of that one object--I have this little piece of this computation to do with limited resources, how am I going to accomplish it?

Over time, the ability to simultaneously hold both perspectives seems to soak into the brain. Less and less gets written on the cards. Then the cards are blank. After a while people just point to where the card would be if they would bother taking a blank one off the stack. Eventually, people have the benefits of the thinking style without needing cards at all. When talking with someone who hasn't mastered the balance, pulling out reals cards can be a useful communication assist, though.

The biggest weakness I find with the cards is the lack of feedback. You can fool yourself about how the code is going to turn out. I would suggest using cards only until an interesting question comes up, turn to tests/code for confirmation, and then resume designing.

Ward and I made a video 15 or so years ago of a design session, but I don't find it online anywhere and I don't have a copy. I'm not sure it would be useful as a teaching tool in any case. I don't know of other videos, but they could be interesting, especially if you got to compare several different designer's styles.

Answer 3

go to the source - Kent Beck, Ward Cunningham, ever heard of them?

Answer 4

I think your statement "I know noone around here who uses CRC cards" pretty much sums up the state of CRC cards in development. CRC cards, in my opinion, were a step on the road from traditional, plan-driven development to agile development. The world has moved on. Instead of focusing on how to use CRC cards, I'd investigate techniques like TDD, which can make use of techniques like UML and CRC cards as intermediate artifacts but which concentrates on code, and more particularly on tests. This is the direction that the inventors of CRC cards have taken and I'd recommend that you take also.

Answer 5

Easiest way to use them in my opinion without getting into a mess is to write down little CRC cards in your file headers like this:

///////////////////////
//* CRC CARD
//*  Class: UISliderEvent
//*  Responsability: Event that holds the value and id of a Slider's movement
//*  Collaborators: UISlider, UIEvent
//////////////////////

Then everytime you need to add a feature check your card and be sure you don't break any of the contracts you stated in it. Such as all of the sudden depending on UIMouseEvent for example, that's nowhere on the Card so its a no-no to include it.

Answer 6

In their book Object Design: roles, responsibilities, and collaborations published in 2003 Rebecca Wirfs-Brock & Alan McKean discuss CRC cards in some detail. They really emphasise the difference it makes to the whole procedure that this should be a very tactile experience and it loosens people's thinking to be passing round a physical object when trying to flesh out a design / requirement.

The sub-title of that chapter suggests that using the cards is a part of the 'exploratory design' phase so it probably comes prior to doing much coding, but I see no reason you wouldn't keep coming back to them in each iteration of an Agile project and reminding yourself where you thought you were going and reviewing that if need-be (as a group of course).

I seem to remember that they even suggest passing a ball around the room so that only the person that has the ball is allowed to speak, so perhaps it's not so much the CRC cards as the getting everyone in a room talking about roles and responsibilites of objects that matters?

If you'd like to read a case-study of CRC cards in action (in addition to Kent and Ward's original paper of course) then have a look at The CRC card book.