CRC CARDS

1

Sys464Object-oriented analysis and

design

CRC Cards2

CRC Cards were developed by Rebecca Wirfs-Brock to help her students identify classes

Goal of Scenarios3

Describe the requirements of the systemDevelop an execution scenario that

captures important behaviour in the application domain to determine the objects involved in the

execution scenario

Scenarios4

Many Use cases and their associated Scenarios are required to cover the complete behaviour of the objects we instruct the objects how to react to each new

situation

CRC Cards5

CRC Cards describe each class in terms of its responsibilities collaborators

CRC Cards6

4 x 6 Index Cards severely restricts the amount of

information easy to manipulate, shuffle around allows you to “touch” the object

Notes on CRC Description7

Find specific, concrete objects from the application domain tangible and visible things

Notes on CRC Description8

Choose names corresponding to nouns or noun-phrases in the Scenarios Use terms a domain expert would use, not a

programmer

Notes on CRC Description9

Use singular names, not pluralDon’t worry about different varieties

of similar objects (at this stage) they often appear as adjective-noun phrases

like check in screen, main library screen

Notes on Class Responsibilities10

“A responsibility is anything that a class knows or does.”

“Important: A class is able to change the values of the things it knows, but it is unable to change the values of what other classes know.”

Source: Scott W. Ambler, Agile Modeling

Notes on Class Responsibilities11

Responsibilities should be action verbs

Important to flesh out, “Keep track of…” type of responsibility

Responsibilities often come in pairs; you should note them in this style

Notes on CRC Descriptions12

More than one class may seem to have the same responsibility This is fine since one object may simply forward

the responsibility to the other e.g. both the car and an engine may have “starts

itself when requested” responsibility. The car simply forwards its request to the engine; the engine does the real work

Notes on CRC Descriptions13

Collaborators should be associated with individual responsibilities

Don’t try to capture ‘flow of control” with CRC’s We will use sequence diagrams to capture that

information

Notes on CRC Descriptions14

Some objects will necessarily be busier than others

You may find improvements to the real-world model but it is always the best place to begin

Notes on CRC Descriptions15

Expect CRC descriptions to change over time they should always describe your current system

Model only the “front end”; I.e. We don’t need to worry about the host-side of the computation

Notes on CRC Descriptions16

Think about the real objects which exist in the domain

Summary of CRC Process17

Purpose is to identify important types of objects (classes).

Responsibilities act as a “contract” between the objects

Collaborators illustrate explicit dependencies to fulfill responsibilities

Summary of CRC Process

CRC’s represent a contract between team members as well as objects.

Everyone must be on board!

18