This chapter is from the book
This chapter is from the book
This chapter is from the book
CRC Models
Ward Cunningham and Kent Beck developed the CRC technique.4 The technique consists of using a small index card (see Figure 8.6) that contains the name of the class, the responsibilities of the class, and the names of other classes with which the class collaborates.
)
Figure 8.6 Beck-Cunningham CRC card.
A short description of the purpose of the class may be written on the reverse of the card. The technique was developed to allow the designers and users of the system to quickly describe the classes in the system. The resulting index cards can be placed on a table and arranged spatially to interactively develop a model of the system. A variation on the technique, which I have found to be very useful, is to assign the class cards to the people who are involved in the design project. Each person "becomes the class" by playing that class's role in a typical scenario. It is important that the designers think in terms of the service responsibilities of the class instead of the data responsibilities of the class. As a rule of thumb, each class should have only about two to three responsibilities. These responsibilities will be implemented in approximately 10 to 12 operations of each class. Each operation will eventually be programmed in approximately 4 to 30 lines of code.
The whole group can quickly verify communication paths, test the completeness of the design, uncover hidden design assumptions, develop a glossary, and so on. I have found it useful to pass a ball or other object among the team members that represents the system's thread of control. The person passing the ball attaches a message that requires a service from the recipient of the ball. The person who receives the message keeps the message and then either sends requests for service from other objects (the object's collaborators) or returns the requested response back to the requester. At the end of the exercise, each person will have a collection of messages that will represent the operations of the objects that they are responsible for developing. During the design phase of the project, the policies, rules, directives, and algorithms that will be required to implement these operations will be identified and eventually programmed.
The final step of the CRC role-playing exercise is for all of the players to arrange their CRC cards on a tabletop so that the name of their classes are as physically close as possible to the where their class names appear in the collaborator section of the other players' CRC cards. This will produce, in 2 or 3 minutes, a class diagram for the project.
David Taylor has modified the CRC approach (see Figure 8.7) by adding super class and component categories to the card. The super class is the name of the more general class of objects that this class is a member of. For example, the class Sales Order is a member of the more general class called Order. The components are the names of classes that are combined to form the class. For example, the class Sales Order is made up of the combination of Products, Pricing, and Customer classes.
)
Figure 8.7 Taylor CRC card.
Ian Graham has modified the CRC card (see Figure 8.8) to include super classes, parts, attributes and associations, operations, servers-messages, and rule sets. His super class and parts are similar to Taylor's super class and components. Attributes indicate if the class is a primitive data item or a user-defined class. They also indicate initial and default values, whether values can change over the class's lifetime, security levels, ownership, the possibility of null values, and valid range constraints. Associations show the cardinality of the relationships the class has with other classes. Operations are the procedures that the class can perform. Servers-messages indicate the messages that the class can receive. Rule sets show the constraints and business rules that apply to this class. Changes in state of the class may be recorded on the backs of the cards during role-playing or walk-through exercises.
)
Figure 8.8 Graham class card.
Ian Graham's extensions to the use case and the CRC card techniques are designed to provide additional details to the people who will actually have to implement the model. I agree with his additions, but I am very much in favor of including formal design contracts into the use case and the CRC cards. Graham's extensions are intended to assist people who will still be creating code. My extensions are intended to assist people who will be assembling existing classes.