User:NcsuOO517
Class Responsibility Collaboration (CRC) Cards
Overview
A Class Responsibility Collaboration card session is a useful procedure in designing object-oriented programs. CRC cards provide a visual layout of how a program can be divided up into classes to optimize efficiency and organization.
History
CRC Cards were invented by Kent Beck and Ward Cunningham in 1989 when object-oriented programming was a new concept for most programmers. They used the cards to teach object-oriented design in a way that procedural programmers could understand. As OO programming became more popular, the use of CRC cards expanded. Their ease of use and ability to represent an entire program's functionality and interactions make them helpful for multiple stages of design; consequentially, they are now commonly used as a routine part of the software development process.
What does a CRC card look like?
Basics
A CRC card is an index card that is divided into three sections: Class at the top, Responsibilities on the left and Collaborators on the right.
Class - The name of the object the CRC card represents.
Responsibilities - The functions the class should implement. These typically correspond to the methods to be included in the class.
Collaborators - A list of other classes that the current class will interact with.
Variations
Just as there are variations in any software development process, some CRC cards have other features implemented.
Main Responsibility - Defines the sole function of a class. As there should only be one clearly defined main responsibility, this field is often useful in determining if a class should be split up into two or more individual classes. It is typically featured underneath the Class box.
Attributes - The attributes the class should have. These typically correspond to the instance variables to be included in the class. If attributes are included, they are featured on the back of the index card.
A CRC Card Session
A CRC card session can be held by an individual, but it is more commonly held by a group. As with many processes, a group is typically better for a CRC exercise since one person may think of something another does not. Sessions can be held anytime in the development process. At the beginning it is an excellent brainstorming exercise, but it is also useful for evaluating the design after development has been implemented. Steps:
1. Brainstorm the Objects: The session begins by reading through a scenario or use case for the program and highlighting all the objects, or interactive nouns, mentioned. Each object is written on its own card as the class name.
2. Add Responsibilities and Collaborators: Once the initial objects are created, the action verbs related to an object become its responsibilities. If a responsibility requires interaction with another object, the object should be listed as a collaborator.
3. Divide and Merge Objects: The scenario should be well thought out to include possible alternatives so that the cards are a good representation of the objects. As the cards are built, it becomes clear that an additional object may need to be created to lighten the responsibilities of another; likewise, some objects may have only one small responsibility which can be merged with other objects. The optional Main Responsibility field on the cards also helps with this merging and splitting process. If the responsibilities cannot be summed up into one main responsibility, the object should probably be divided.
The steps are repeated until a clean, clear, and concise design is represented on the cards.
Example
References
1. Cockburn, Alistair. Using CRC Cards. 1999. [1]
2. Wilkinson, Nancy M. Using CRC Cards: An Informal Approach to Object-Oriented Development. Cambridge University Press, 1998.
3. Williams, Laurie. CRC Cards. 2006. [2]