Search in Book Reviews

CRC in this case stands for Class, Responsibilities and Collaborations (and not Cyclic Redundancy Check as you might suppose). CRC cards form the basis of an informal technique for evaluating sets of candidate classes. Each card describes a class and lists the responsibilities of the class and the other classes that it may collaborate with. Various scenarios that the finished software will have to accommodate are then 'role-played' by the design team using the cards.

This book describes the CRC technique (as you might expect from the title), but also has more general advice about Object Oriented (OO) projects in general. There is the ubiquitous chapter on OO terminology, a chapter on managing OO projects and a brief round up of popular methodologies (UML and Schlaer-Mellor) with examples of how the CRC technique can be applied to them and a brief discussion of the various OO Software Development Life Cycles.

The authors emphasise that CRC is NOT a methodology, but a technique that harnesses the 'creative powers' of a group; 'brainstorming' produces sets of candidate classes, while 'role playing' refines the relationships between the candidate classes. There is plenty of discussion of how to select the group members, how to make them feel at ease with each other, how to manage a group session, etc. The terminology used may make you feel uneasy - brain-storming, facilitator, metacognitive process, and role-play all come complete with new-age connotations.

This feeling is not helped by the 'Case Studies' presented. There are three case studies - stocks and bonds, clothes design and traffic control. The case studies are presented as transcriptions of group meetings. The characters that populate these meetings are well balanced, stereotype breaking and completely unbelievable. The book is not supposed to be a novel, so character development is not required. Still, there is something strangely bizarre about writing the follow-ing about even the most two dimensional character: 'This gave Ellen the idea of a TrafficStream class', 'Brig conceded that this was true' or 'Joan decided to pass around a few brain teasers to get everyone going'. These are more Ant and Bee than OOD.

However, almost all of the information presented is valuable and accessible if you can ignore some of the method of presentation. We have all struggled with the selection of core classes in a new project and CRC offers the possibility of system architects, domain experts and software engineers working together to form an initial design of a system.

The chapter on managing object analysis is ideal for showing to your manager when they start to talk about moving to OO. Everything from choosing a pilot project to designing metrics to measure progress is covered. There is also a strong emphasis on the need for training, which has been overlooked in many of the organisations that I have worked within.

There are chapters on implementing CRC cards in Smalltalk, C++ and Java. The C++ section gave brief, but useful, coding guidelines. Their use of constructor parameter classes was particularly insightful, as were their warnings about proprietary GUI class frameworks (especially Microsoft's MFC). They do stress that for most projects CRC cards themselves are not enough to implement a solution and that a transition to a formal methodology will be necessary.

The book closes with a brief survey of CRC card software, which dwells on the merits of the Rational Corporation offering. I hope that this is because the package merits recommendation and not because Grady Booch is the series editor for Addison Wesley.

I liked (most of) this book. CRC has long been of interest to me and it is described in full, along with its limitations. If you have always wanted your job title to be 'facilitator' then this is definitely the book for you. For the rest of us, I would recommend skimming through (or skipping) the case studies.