Customer chooses to withdraw cash from checking. Sufficient cash is in the account,
sufficient cash and receipts are in the ATM, and the network is up and running. The
ATM asks the customer to indicate an amount for the withdrawal, and the customer
asks for $300, a legal amount to withdraw at this time. The machine dispenses $300
and prints a receipt, and the customer takes the money and the receipt.Assume there are five participants in the CRC session: Amy, the facilitator and object-
oriented designer; Barry, the lead programmer; Charlie, the client; Dorris, the domain
expert; and Ed, a programmer.
Amy holds up a CRC card representing CheckingAccountand says “I tell the customer
how much money is available. He asks me to give him $300. I send a message to the dis-
penser telling him to give out $300 cash.” Barry holds up his card and says “I’m the dis-
penser; I spit out $300 and send Amy a message telling her to decrement her balance by
$300. Who do I tell that the machine now has $300 less? Do I keep track of that?”
Charlie says, “I think we need an object to keep track of cash in the machine.” Ed says,
“No, the dispenser should know how much cash it has; that’s part of being a dispenser.”
Amy disagrees: “No, someone has to coordinate the dispensing of cash. The dispenser
needs to know whether cash is available and whether the customer has enough in the
account, and it has to count out the money and know when to close the drawer. It should
delegate responsibility for keeping track of cash on hand—some kind of internal account.
Whoever knows about cash on hand can also notify the back office when it is time to be
refilled. Otherwise, that’s asking the dispenser to do too much.”
The discussion continues. By holding up cards and interacting with one another, the
requirements and opportunities to delegate are teased out; each class comes alive, and its
responsibilities are clarified. When the group becomes bogged down in design questions,
the facilitator can make a decision and help the group move on.
Limitations of CRC Cards Although CRC cards can be a powerful tool for getting
started with design, they have inherent limitations. The first problem is that they don’t
scale well. In a very complex project, you can be overwhelmed with CRC cards; just
keeping track of them all can be difficult.
CRC cards also don’t capture the interrelationship among classes. Although it is true that
collaborations are noted, the nature of the collaboration is not modeled well. Looking at
the CRC cards, you can’t tell whether classes aggregate one another, who creates whom,
and so forth. CRC cards also don’t capture attributes, so it is difficult to go from CRC
cards to code. Most important, CRC cards are static; although you can act out the inter-
actions among the classes, the CRC cards themselves do not capture this information.
In short, CRC cards are a good start, but you need to move the classes into the UML if
you are to build a robust and complete model of your design. Although the transition into356 Day 11