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 - Any attributes to be associated with the class. 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
Use Case: Checkout at a Grocery Store
Main Flow
A customer brings a collection of products to a register. The cashier scans the products. The register displays the total cost, and the customer chooses a method of payment [S-1]. The cashier puts the customer's purchases in a bag and hands the bag to the customer. The customer leaves the store.
Subflows
S-1: Method of payment. If the customer chooses to pay with a card, the customer slides the card in the ATM machine and presses the appropriate buttons. If cash, the customer hands some amount of cash to the cashier [S-2].
S-2: Amount of cash. The customer hands too little cash, and the cashier must prompt the customer for more [S-3]. The customer may hand too much, so the cashier returns the appropriate amount of change from the register to the customer. The customer may also hand over exact change.
S-3: Too little cash. The customer could either hand over more, or may not have enough to pay for the purchase, in which case the cashier must remove one or more items from the order.
CRC Session
1. Brainstorm the Objects
a. First we scan the use case for nouns:
customer products register cashier cost payment_method purchases bag card ATM_machine buttons cash change order
b. Next we can eliminate obvious duplicates (this requires some logic!). For example, cash, card, payment_method, and change are all associated with money and can be combined. Here's a sublist of the nouns:
customer product register cashier money bag ATM_machine order
c. Finally we make cards for each of these objects.
2. Add Responsibilities and Collaborators
a. For responsibilities, we look for action verbs: "A customer brings a collection of products to a register." Again, we need to use some logic; is "to bring" a necessary responsibility for the customer? This could depend on what the overall goal of the system is, but in this case the main focus is on the checkout process. Perhaps to modify this statement, we could include a responsibility for the customer to add a product to the order.
b. Next, we must decide if the responsibility requires collaboration with another object. For the customer to add a product to the order, the customer must interact with the order object.
c. We continue this until we have covered all of the main and subflows in the use case.
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]