User:NcsuOO517

Overview

A Class Responsibility Collaboration (CRC) 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

Class Responsibility Collaboration 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 object-oriented 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. [3]

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. The class name should be singular (i.e. Server, not Servers) and simple (Server, not Worker Who Takes Orders). [1]

Responsibilities - The functions the class should implement. These typically correspond to the methods to be included in the class. One responsibility of a server would be to add an order to a kitchen queue.

Collaborators - A list of other classes that the current class will interact with. For example, a server only knows information about himself. In order for the server to add an order to the queue, he must retrieve information about the order (such as what dish it is). He must also interact with the queue to know where to put the order. [1]

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.

For more information about optional features see Laurie Williams' presentation on CRC cards.

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. Also, a group with enough people can distribute one card to each person when brainstorming responsibilities [4]; for example, one person may get the Waiter card while another gets the Queue. If each person tries to think only within the scope of their class, it becomes easier to establish responsibilities and collaborators when running through a scenario. In their documented experiences with teaching the CRC card technique, founders Kent and Cunningham state that "it is not unusual to see a designer with a card in each hand, waving them about, making a strong identification with the objects while describing their collaboration" [5].

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. [2] 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. For a more detailed breakdown of the CRC session steps, see Alistair Cockburn's memo on Using CRC Cards.

The best way to understand the different steps of a CRC Card session is through an example.

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 customer finishes paying and the cashier hands the customer a receipt.

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 card ATM_machine buttons cash change items order transaction receipt

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 ATM_machine order receipt

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 other objects. For the customer to add a product to the order, it appears the customer must interact with both the product and order objects.

c. We continue this until we have covered all of the flows in the use case. The resulting CRC cards should look something like this:

3. Divide and Merge Objects

By examining the generated cards it is clear to see that some need to be eliminated. Money and receipt have no responsibilities attached to them because they are not interactive nouns, so they can be thrown out. Objects such as Product, ATM Machine, and Order have few responsibilities which all consist of "getter" methods. On the other hand, Cashier has a seemingly large amount of responsibilities. It is not always obvious what the best course of action would be for these situations. After dividing, removing and merging cards, a final set may look similar to the following:

The CRC cards help to visualize each class, saving time on redesigning the actual program. This example showed that the merge of the product and order classes made sense; without the card session, this may not have been discovered and functionality would be repeated. Similarly we can see that some responsibilities, such as calculating the total price of the order, could be redistributed to lighten the responsibilities of an overloaded object. Also, even though some cards like Money and Receipt had no responsibilities, their removal caused the need to rethink the responsibilities of other classes to be sure all were addressed; this is evidenced by the new responsibilities of the Register class card.

References

1. Ambler, Scott W. Class Responsibility Collaborator (CRC) Models. Ambysoft Inc, 2009. [1]

2. Cockburn, Alistair. Using CRC Cards. 1999. [2]

3. Wilkinson, Nancy M. Using CRC Cards: An Informal Approach to Object-Oriented Development. Cambridge University Press, 1998.

4. Williams, Laurie. CRC Cards. 2006. [3]

5. Williams, Laurie. Requirements Engineering. [4]