CSC/ECE 517 Fall 2011/ch4 4i sd

"CRC Card Tools"

---

CRC Cards

CRC Cards are the Class Responsibility Collaboration Cards which are used to interactively brainstorm an initial design of a program or a program segment. These are used as a tool used in the design on object oriented software.<ref name="crc">CRC Cards - Wikipedia</ref> CRC Cards were invented by Kent Back and Ward Cunningham in 1989.<ref name="paper"> Beck, Kent; Cunningham, Ward (October 1989), "A laboratory for teaching object oriented thinking", ACM SIGPLAN Notices (New York, NY, USA: ACM) 24 (10): 1–6, doi:10.1145/74878.74879, ISBN 0-89791-333-7</ref> It supports a rapid and thorough exploration of design alternatives. It is used during initial model construction as a brainstorming technique where it is used to determine which classes are needed and how they will interact among themselves, and again later to evaluate the design. Normally, it could be done by one person or may require up to five people.<ref name="alistair">CRC Cards</ref>

CRC cards explicitly represent multiple objects simultaneously. However, rather than simply tracing the details of a collaboration in the form of message sending, CRC cards place the designer’s focus on the motivation for collaboration by representing (potentially) many messages as a phrase of English text.<ref name="paper"></ref>

Description of CRC

The CRC cards are commonly created from 4 by 6 inch index cards and they contain:

• Class - the name of the object-oriented class
• Responsibility - the responsibilities of the class
• Collaborator - the relationship the class has with other classes in order to collaborate and fulfil its responsibilities

To identify the name of the classes, we look for the nouns in the requirements document. The class should be a singular noun, does not really have the same functionality as some other class, and is not a primitive type.

Responsibility-driven modelling can be done using CRC cards. These could also be used to form object interaction diagram. The advantage of using a small index card is that they are cheap, portable, readily available, and familiar.<ref name="paper" /> Since these cards are small in size, they help reduce the complexity of the design to minimum. It focuses the designer on the essentials of the class and prevents her/him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

Steps in making CRC Cards

1. Identify and assign candidate classes 2. Determine a set of specific scenarios 3. Walk through the scenario, naming cards and responsibilities 4. Write the main responsibility for each class 5. Identify the responsibilities for each class 6. Identify one or more collaborators for each class

Example of a CRC Card

Here is an example of how a CRC Card looks.<ref name="dennis">Dennis, Wixom, Roth, "Systems Analysis and Design", 3rd Edition</ref>

• Front Side of a CRC Card

• Back Side of a CRC Card

CRC Card Tools

• QuickCRC
• HotDraw
• CRC Design Assisstant
• EasyCRC Tool
• Software Ideas Modeler
• Use Case Driven Design Using XML

Conclusion

CRC cards give the learner who has never encountered objects a physical understanding of object-ness, and prepares them to understand the vocabulary and details of particular languages. CRC cards also give useful and convincing experience with objects to those who has learned the mechanisms of objects but do not yet see their value. We speculate that because the designs are so much more concrete, and the logical relationship between objects explicit, it is easier to understand, evaluate, and modify a design. It is just this problem-integrating the cards with larger design methodologies and with particular language environments, that we feel holds the most promise for the future. The need to retain the value of physical interaction points to the need for a new kind of user interface and programming environment as far beyond what we have today as our current systems are beyond the tool-oriented environments of the past.<ref name="paper" />

References

<references/>