CSC/ECE 517 Fall 2011/ch4 4i aa

"CRC Card Design Tools"

Class-Responsibility-Collaborator Cards were "invented to document collaborative design decisions."<ref name="beck">"A Laboratory For Teaching Object-Oriented Thinking" by Beck and Cunningham</ref> They are a way to discover classes, determine the responsibilities of each of those classes, and describe their relationships. The information for each class is written on a separate card.<ref name="lecnotes">Lecture Notes</ref> This article will discuss CRC cards and how well they have been implemented in several modern software packages.

Introduction

A CRC card is a notecard laid out in a particular fashion where one may define a class, its responsibilities, and collaborators (see figures below). In this definition, a class refers to an object in the traditional object-oriented sense; responsibilities refers to the actions that the object must take; and collaborators refers to the other objects with which the originally defined class must interact.<ref name="skrien">Skrien, Dale John. Object-oriented Design Using Java. Boston: McGraw-Hill Higher Education, 2009. Print.</ref> In other words, the class name of an object "creates a vocabulary for discussing a design," the responsibilities "identify problems to be solved," and collaborators are "object which will send or be sent messages in the source satisfying responsibilities."<ref name="beck"/>

Class-Responsibility-Collaborator cards are an evolution of simple use cases. In such use cases, “actors” would be defined and a “story” of their actions would be written. Extraction of the nouns and verbs in these stories would be leveraged in an effort to help determine the relevant classes and methods.<ref name="skrien"/>

One of the benefits of CRC cards is their portability since they are made using 4"x6" index cards because they are "cheap, portable, readily available, and familiar."<ref name="beck"/> Another benefit is their ability to design systems without drilling down into low-level details, but having the extensibility to do so if required.<ref name="skrien"/> A third benefit of CRC cards is their ability to be incorporated into genuine human interactions where developers could role play. In these interactions, developers would be given blank cards and use cases would be acted out. As the use case is performed, classes and actions are written down and refined, ultimately resulting in a comprehensive class definition.

The physical spacial arrangement of the cards can have informal meaning:

• When cards overlap it can mean that the objects represented by the cards are collaborating
• A card placed above another card can mean that the object it represents is supervising the object represented by the card below
• Cards representing parts are usually placed below the card representing the whole
• "Refinements of an abstraction can be collected and handled as a single pile of cards with the most abstract card on top where it can represent the rest"<ref name="beck"/>

Refining the role-playing suggestion above, Beck and Cunningham "suggest driving a design toward completion with the aid of execution scenarios. We start with only one or two obvious cards and start playing "what-if". If the situation calls for a responsibility not already covered by one of the objects we either add the responsibility to one of the objects, or create a new object to address that responsibility. If one of the object becomes too cluttered during this process we copy the information on its card to a new card, searching for more concise and powerful ways of saying what the object does. If it is not possible to shrink the information further, but the object is still too complex, we create a new object to assume some of the responsibilities." The goal of this exercise is to "encourage designers to pick up the card whose role they are assuming while 'executing' a scenario and stress the importance of creating objects not to meet mythical future needs, but only under the demands of the moment. This ensures that a design contains only as much information as the designer has directly experienced, and avoids premature complexity."<ref name="beck"/>

Due to the tactile nature of CRC cards, computerization of them may seem to "defeat the point." Indeed, Beck and Cunningham think that "when designers pick up a card they seem to more readily identify with it, and are prepared to deal with the remainder of the design from its perspective. It is the value of this physical interaction that ... resist[s] a computerization of the cards."<ref name="beck"/> This article will perform a survey of the computerization of this design methodology, keeping in mind that these tools may not provide the same user experience and ultimately the same design results as the use of physical cards can. The main criteria for successful execution of computerization will be how well the application can mimick the actions of using physical cards.

Tools

Stickies

Probably the simplest way to reproduce CRC cards on a computer is using applications like Stickies on the Mac OSX and Sticky Notes on Microsoft Windows 7.

On Mac OSX a Sticky note looks like

Mac OSX Stickies vs. Windows 7 Sticky Notes

Feature	Mac OSX	Windows 7
Change the background color of a note	✔	✔
Format text using different fonts and colors	✔	✔
Collapse and expand a note	✔
Insert images and videos into a note	✔
Make a note translucent	✔
Create a new note from the text selected in an application	✔
Import/export the content of a note	✔
Spell checker	✔
Add scrollbars to a note	✔
Support pen and touch input		✔

QuickCRC

//TODO Intro here.

Example of a CRC card and of a scenario

Front of the CRC card	Back of the CRC card	Scenario

The content of a CRC card is self-explanatory.

"A scenario describes what happens in the system from a high-level, user’s point of view. The goal of walking through scenarios is to discover where additional classes, responsibilities and collaborations are required or where existing items have become redundant." [QuickCRC Tutorial PDF]

For example the above scenario says that in order to write a document out to disk the UI (AnyClient) calls the Write responsibility of the TDocument object. Then the TDocument calls the EachItemDo responsibility of the TList object to loop through all the shapes contained in the document and finally the TDocument calls the Write responsibility of each TShape object.

If a step in a scenario is particularly complex it can be modeled and detailed by a subscenario.

You can walk through a scenario mentally or you can use a tool that plays the scenario step by step. At each step the tool reports who's calling who and all the descriptions associated to the sender, receiver and responsibility called. This can help identifying missing or redundant pieces in the design (classes, responsibilities, attributes).

In QuickCRC all the information in the cards can be dragged around into other cards and the tool takes care of establishing the appropriate relationship among the cards. For example if class TEventHandler is supposed to be the superclass of TWindow you can drag the TEventHandler card name into the Superclasses: field of the TWindow card. Or if you need to move a responsibility or an attribute from one class to another you can just drag the responsibility/attribute from the origin card to the recipient card. A class can inherit from multiple classes but the tool won't solve method name conflicts for you.

The tool can keep track of eternal agents like a user or other systems that typically drive or influence the functioning of the system being designed.

If the system to design is large, the tool will allow you to split the cards into multiple diagrams so that you can deal with only a manageable subset of cards at any time.

The tool allows to arrange cards and scenarios based on different criteria.

The tool can generate graphs to show the inheritance structure to show all the subclasses of a particular class for example.

Once the design reaches a point where implementation can start, the tool can generate a listing of all the classes in the system with relative attributes and responsibilities. This listing is then handed over to the programmers.

The design can also be exported into a text file that can be imported by the QuickUML modeling tool.

On the other hand the tool can import English text that describes the system you are trying to design and it will attempt to derive classes from nouns in the text, attributes from adjectives and responsibilities from verbs and it'll auto-generate cards accordingly.

If you are trying to reverse engineer existing source code, you can use tools like WinTranslator or MacTranslator to extract design information from the source code into a dictionary entries list that then can be imported into QuickCRC that will automatically populate a new project with cards that reflect the design information gathered by the other tools.

Visual Paradigm for UML

VP-UML is a CASE tool. It supports CRC card diagrams as part of the requirements management workflow. VP-UML provides tools to support many other workflows such as UML modeling, business process modeling, database modeling, UI modeling, reverse engineering and more.

These are some of the peculiarities of the tool that supports CRC card diagrams:

• It can generate UML class diagrams automatically out of the CRD cards.
• A class diagram can also generate Java code for the classes directly inside Eclipse
• All properties in a CRC card must be edited inline. To edit, double click on the desired field, update its value, and click on the diagram background to confirm editing. (from here)
• Cannot drag and drop values from one card to the other.
• You can record audio to associate to a diagram.
• You can decide which portions of a CRC card are displayed (Responsibilities, Attributes etc.)

Conclusion

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

We were surprised at the value of physically moving the cards around. When learners pick up an object they seem to more readily identify with it, and are prepared to deal with the remainder of the design from its perspective. It is the value of this physical interaction that has led us to resist a computerization of the cards.

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." [1 Beck/Cunningham]

Tools feature comparison

Feature	QuickCRC	VP UML
Model scenarios	✔
Drag values from card to card	✔
Generate UML class diagrams	✔	✔
Handle subdiagrams	✔	✔
Generate Java code		✔
Collapse/expand cards	✔
Display/hide parts of a card		✔
Export/import card diagrams to/from text files	✔	✔
Arrange cards based on different criteria	✔	✔

arrange cards and scenarios based on different criteria

References

<references/>

[1] Beck/Cunningham

[2] CRC Cards: An Agile Thinking Tool

[3] CRC cards on Wikipedia

[4] Hot Draw

More a programming tool than design [5] HyperCard

More a programming tool than design [6] HyperCard Group

More a programming tool than design [7] SuperCard

Acquisition made this obsolete it seems [8] MetaCard

Acquisition made this obsolete it seems [9] MetaCard Group

More a programming tool than design [10] Revolution

More a programming tool than design [11] PhytonCard

More a programming tool than design [12] FreeCard

More a programming tool than design [13] FreeCard Group

Aldo [14] Visual Paradigm for UML

Aldo [15] QuickCRC

Andy will evaluate [16] Software Ideas Modeler

Andy will evaluate [17] CRC Card Editor

Aldo [18] Stickies on Mac

Andy will evaluate [19] Sticky Notes on Windows 7