CRC Card

Definition

Class Responsibility Collaborator (CRC) card

a business architecture and application design work product consisting of a large index card that informally documents the responsibilities and collaborators of a:

• Type during:
  • Architecting of the business object model
  • Requirements analysis of the application domain model
• Class during:
  • Software design and the programming of class comments

Objectives

The typical objectives of a CRC card are to:

• Informally document the responsibilities and collaborators of a type or class.
• Promote a responsibility-driven design.

Benefits

The typical benefits of a CRC card are:

• By promoting a responsibility-driven design, CRC cards:
  • Maximize object abstraction, cohesion, and encapsulation.
  • Minimize delegation (message and exception) coupling.
• CRC cards are very inexpensive and user friendly.
• CRC cards provide the information needed to:
  • Begin programming of classes.
  • Commenting classes to support the generation of Javadoc.

Contents

The typical contents of a CRC card are:

• Front Side:
  • Name of the type or class
  • Responsibilities of the class (responsibilities for doing, knowing, and enforcing business rules)
  • Associated collaborators
• Back Side:
  • Package (OML or UML)
  • Description of the type or class

Stakeholders

The typical stakeholders of a CRC card are:

• Producers:
  • Requirements Team, which creates CRC cards during the elicitation and analysis of an application’s domain model.
  • Architecture Team, which creates CRC cards during the:
    • Architecting of the business (business engineering).
    • Prototyping of the executable software architecture (application development).
  • Software Development Team, which creates CRC cards during the design of an application’s software.
• Evaluators:
  • Requirements Team, which evaluates the CRC cards produced by the architecture team.
  • Architecture Team which evaluates the CRC cards produced by the requirements team and the software development team.
• Approvers:
  • None
• Maintainers:
  • None
• Users:
  • Requirements Team, which may use CRC cards during the specification of the domain model document.
  • Architecture Team, which may use CRC cards during the production of the executable software architecture prototype.
  • Software Development Team, which may use CRC cards during the object-oriented design of software components and the coding of class comments to support Javadoc.

Phases

A CRC card is typically developed during the following phases:

• Business Strategy: Completed for business architecture
• Business Optimization: Not Applicable
• Initiation: Completed for domain object model
• Construction: Completed for software design
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

CRC cards typically can be started if the following preconditions hold:

• The initiation phase is started.
• The relevant team(s) are staffed and trained in responsibility driven design.

Inputs

The typical inputs to CRC cards include:

• Work Products:
  • Business Engineering:
    • Glossary
    • Customer Analysis
    • Market Analysis
    • User Analysis
    • Business Vision Statement
  • Application Development:
    • Glossary
    • System Requirments Specification
    • Domain Model Document
    • System Architecture Document
    • Software Architecture Document
• Stakeholders:
  • Business Domain Experts
  • Application Domain Experts

Guidelines

• Use the CRC cards mostly as an elicitation and modeling techniques, rather than as a documentation tool.
• As soon as practical, transfer the information into deliverable documents or Java class comments. There is little benefit in maintaining the CRC cards thereafter.
• Use large index cards; the small ones are too little to hold the necessary information.
• Concentrate on the responsibilities for doing and enforcing rather than for knowing (which promotes a data-driven design).
• List collaborators across from the associated responsibilities so that readers can tell which collaborators help implement which responsibilities.
• During requirements elicitation and analyis, concentrate on types rather than their implementations (classes).

Conventions

CRC cards are typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• MS Word Template
• XML Template
• Inspection Checklist

Examples

• Example CRC card