Using CRC Cards
(Class-Responsibility-Collaboration)

H. Conrad Cunningham

23 February 2022

Copyright (C) 2018, 2022, H. Conrad Cunningham

Acknowledgement: These notes are based, in part, on material from chapters 3, 4, 5, and 6 of Bellin [2].

Advisory: The HTML version of this document requires use of a browser that supports the display of MathML. A good choice as of February 2022 is a recent version of Firefox from Mozilla.

Objectives

What are CRC Cards?

CRC Card Preview

Class Name
description of responsibilities
Collaborators
other classes

What Goes On CRC Cards?

CRC Card Layout

Class Name
description of responsibilities
Collaborators
other classes

Who Writes CRC Cards (1)

Who Writes CRC Cards (2)

Brainstorming

Use brainstorming session to collect ideas quickly and creatively

Brainstorming Principles

  1. All ideas are potentially good ideas

    Don’t censure yourself or others — All ideas are equal

  2. Think fast and furiously; ponder later

    Fast-paced discussion encourages individual creativity

  3. Give every voice a turn

    Include everyone in group — no loudmouth domination

  4. A little humor can be a powerful force

    Humor can break barriers, relieve tension, and build trust

Candidate Class Sources (1)

Before session, assign each team member an investigative task

Candidate Class Sources (2)

A good analyst is a good detective!

Identifying verbs and verb phrases may help find responsibilities later

Landshark Bank ATM (1)

Landshark Bank, a new bank opening next summer, plans to provide a full service automated teller machine (ATM) system.

The ATM system interacts with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.

Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.

Customers are assigned a Personal Identification Number (PIN) and clearance level by the security system. The PIN can be verified prior to any transaction.

In the future, we plan to support routine operations such as a change of address or phone number using the ATM.

Landshark Bank ATM (2)

Landshark Bank, a new bank opening next summer, plans to provide a full service automated teller machine (ATM) system.

The ATM system interacts with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.

Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.

Customers are assigned a Personal Identification Number (PIN) and clearance level by the security system. The PIN can be verified prior to any transaction.

In the future, we plan to support routine operations such as a change of address or phone number using the ATM.

Brainstorming Steps (1)

  1. Review brainstorming principles

  2. State session objectives

    • Have a precise objective — clear to all, narrow enough to accomplish in session

    • Avoid digression from objective

Brainstorming Steps (2)

  1. Use a round-robin technique

    • Go from individual to individual

    • Individuals may “pass” if they have nothing to contribute

    • Stop when no one has anything to contribute

Brainstorming Steps (3)

  1. Discuss and select

    • Restate objective

    • Organize candidate classes into 3 categories by consensus — “winners” — “losers” — “maybes”

    • Discuss “maybes” for fixed time to decide if “winner” or “loser”

    • Postpone “maybe” items if more information needed to decide

Candidate Classes for ATM

ATM FinancialTransaction BankCard
BankCustomer PIN Account
SavingsAccount CheckingAccount Transfer
Withdrawal Deposit BalanceInquiry
Receipt ReceiptPrinter Keypad
Screen CashDispenser ScreenMessage
Display FundsAvailable DepositEnvelopeFailure
Balance TimeOutKey TransactionLog
Key AccountHolder Printer
ScreenSaver Prompt NumericKey

Identify Core Classes (1)

Divide candidate classes into categories in following order:

  1. critical classes (“winners”), for which we will write CRC cards

    Items that directly relate to main entities of application

    ATM example: Account, Deposit, Withdrawal, BalanceInquiry

Identify Core Classes (2)

  1. irrelevant candidates (“losers”), which we will eliminate

    Items that are clearly outside the system scope

    ATM example: Printer, ScreenSave, and Prompt -- related to user interface done later, but not to core banking application

Identify Core Classes (3)

  1. undecided candidates (“maybes”), which we will review further

    Items that we cannot categorize without clarifying system boundaries and definition

    ATM example: What is an “ATM”?

CRC Card for Account, Phase 1

Account
description of responsibilities
Collaborators
other classes

Clarify System Scope

ATM example: What is scope of the ATM system?

Decision: Limit scope to banking information capture, leave user interface and account update to other systems

Identify Commonalities & Variabilities (1)

Commonality (frozen spot): part of system unlikely to change from one system variant to another [3]

Variability (hot spot): part of system likely to change from one system variant to another [3]

Identify Commonalities & Variabilities (2)

ATM example hot spot: Withdrawal handling

Use Appropriate Design Patterns

Design pattern: design structure successfully used in similar context in past — reusable design

ATM example: Interactions of ATM with outside entities might be modeled using local “system interaction pattern”

Result would be new core class AuthorizeSystemInteraction

Leverage Existing Frameworks

Software framework: collection of abstract and concrete classes that captures architecture and system operation

Extend framework classes to customize behavior

“Upside down library” — system control resides in framework code that calls “down” to user-supplied code

Example: Graphical user interface toolkits like the Java Swing

Eliminate Unneeded Core Classes (1)

Eliminate Unneeded Core Classes (2)

Distinguish Attributes & Classes (1)

Some candidate classes may represent information held by others

May be an attribute rather than a class if:

Distinguish Attributes & Classes (2)

Consider PIN from ATM example:

Core Classes for ATM

Undecided Classes for ATM

Irrelevant Items for ATM

Outside scope (most part of user interface system)

Naming (1)

Naming (2)

Characteristics of a Good Class

If class has limited (e.g. one) responsibility, then reconsider whether to keep it (e.g. to promote reuse) or combine with others.

Assigning Responsibilities (1)

Assigning Responsibilities (2)

Responsibility Detection (1)

  1. Brainstorm first. Refine later.

    Use brainstorming to identify set of candidate responsibilities for core classes

    Verbs that occur in requirements documents etc. may indicate behaviors (operations) that must exhibited

    Include rather than exclude. Don’t worry about duplication

    Refine lists later

    Name each carefully

Responsibility Detection (2a)

  1. Think simple. Factor out complexity.

    If most responsibilities cluster in one or two classes, then probably not good OO design — does not exploit polymorphism and encapsulation

    ATM example:

    • Might give most responsibility to Account — strong “manager” procedure giving commands to weak “workers”
    • Account probably too inflexible and others too insignificant to reuse
    • Give each class distinct role — make each well-defined, complete, cohesive abstraction — increase reusability

Responsibility Detection (2b)

ATM example:

-   Give class Withdrawal responsibility "Withdraw Funds" ---
    making potentially useful to any class needing withdrawals
-   Give class Account responsibility "Accept Withdrawal" ---
    done by Withdrawal collaborating with it
-   Factor out complexity by identifying repeatedly occurring
    specialized behaviors --- create appropriate new classes

ATM example:

-   Perhaps factor out capturing and responding to user requests
    
    Introduce new class Form with responsibility "ask user for
    information"

Responsibility Detection (3)

  1. Use abstraction to advantage.

    • Build hierarchies of classes

    • Abstract essence of related classes by identifying common responsibilities — same “what”, different “how”

    • Make these polymorphic operations — defined in abstract base class — given specific responsibility in concrete subclass

    ATM example:

    • Note commonalities among Withdrawal, Deposit, etc.

    • Create abstract base class Transaction with abstract responsibility “execute a financial transaction”

    • Implement responsibility differently for each subclass

Responsibility Detection (4)

  1. Do not marry one solution. Play the field first.

    • Remember CRC cards are inexpensive and erasable!!

    • Experiment with different configurations of classes and assignments of responsibilities

    • Change CRC cards early to avoid changing code later

CRC Card for Account, Phase 2

Account
Know balance
Accept Deposit
Accept Withdrawal
other responsibilities
Collaborators
 
 
 
other collaborators

Assigning Collaborations (1)

Assigning Collaborations (2)

Hierarchy Identification Tips (1)

Hierarchy Identification Tips (2)

CRC Role Play Steps (1)

  1. Create a list of scenarios for use of system (i.e. use cases, user stories, actions to realize requirement)

    Use brainstorming

    ATM example: customer withdraws cash

  2. Assign roles of classes to team members

    Each member has one or more classes

CRC Role Play Steps (2)

  1. Rehearse the scenario

    Execute scenario with team members announcing what affected classes are doing — putting cards into play when used

  2. Correct CRC card and revise scenario

  3. Repeat above two steps as necessary until rehearsal smooth

  4. Perform final scenario

Develop Role-Play Scenarios (1)

  1. Concentrate on “must do” scenarios

    Core behaviors touch central features of system

    ATM example: customer withdraws cash

  2. Develop conditional “can do if” scenarios

    Routine tasks carried out under certain conditions

    Tasks to avoid exceptional situations

    Be careful about crossing out of system scope

Develop Role-Play Scenarios (2)

  1. Record “might do” scenarios (“abuse cases”) to test flexibility

    Exceptions — unusual, complex, difficult to handle cases

    Help uncover poor collaborations and clarify system scope (a stress test)

    ATM example: Withdrawal with insufficient funds

  2. If larger than 25 scenarios in “must do” and “can do if” categories, break into subsystems

Effective Role Play (1)

Effective Role Play (2)

Warm-Up Tips

Scenario Enactment (1)

Scenario Enactment (2)

Scenario Enactment (3)

Scenario Assessment

Wider Use

Summary

References

[1]
Kent Beck and Ward Cunningham. 1989. A laboratory for teaching object-oriented thinking. ACM SIGPLAN Notices 24, 10 (1989), 1–6.
[2]
David Bellin and Susan Suchman Simone. 1997. The CRC Card book. Addison-Wesley, Boston, Massachusetts, USA.
[3]
James Coplien, Daniel Hoffman, and David Weiss. 1998. Commonality and variability in software engineering. IEEE Software 15, 6 (1998), 37–45.
[4]
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1995. Design patterns: Elements of reusable object-oriented software. Addison-Wesley, Boston, Massachusetts, USA.
[5]
Nancy M. Wilkinson. 1995. Using CRC cards: An informal approach to object-oriented development. Cambridge University Press, Cambridge, UK.
[6]
Rebecca Wirfs-Brock and Alan McKean. 2003. Object design: Roles, responsibilities, and collaborations. Addison-Wesley, Boston, Massachusetts, USA.
[7]
Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. 1990. Designing object-oriented software. Prentice Hall, Englewood Cliffs, New Jersey, USA.