Download here

Figure 10. CRC card outlook.
⋅ The component name is written across the top. The responsibilities are written in three
groups.
⋅ First is a brief summary, or synopsis, of the responsibilities of the component, its role in the
system. This should be a short phrase, or perhaps two.
⋅ Next, in a list down the left side of the card are the active responsibilities, with a line or
arrow to the right, ending in the name of a required collaborator for that responsibility. An
active responsibility starts with an active verb, such as "track", "compute" or "find". Avoid
the word "manage" where possible, and the passive verb, "hold".
⋅ Last are the contact point responsibilities, the information the component mediates. Often
these will come from the attributes in a data or business model. If there is some question
whether a service belongs in the active or contact point responsibility section, choose
arbitrarily with a slight inclination toward the contact point section. It really does not matter
a great deal. In the end, all responsibilities will be treated equally. The purpose in having
the sections is so that attention can be focused on the summary and active responsibilities,
which are the primary vehicle for partitioning the system. The contact point responsibilities
are needed for component specification, and to demonstrate how the components deliver
the required function in a documented scenario.
The session
⋅ Use a centrally visible and accessible table.
⋅ Have available a stack of blank CRC cards (see Figure, "CRC Card"). Place them on the table
within reach of anyone or give everyone a set for themselves.
⋅ Before starting a session there needs to be some kinds of requirements for the systems.
Weather they are implicitly or explicitly define the people participating in the group need to
be familiar with them. A session also needs to focus on one part of the problem at a time. So
a subset of the problem needs to be chosen to explore during the CRC card session.
1. Creating class
The first step in modeling a system in the object-oriented paradigm is to identify the
class in the problem domain. So this is the first step in a CRC card session. Using the
problem statement or requirements document, identify the classes that are obvious in the
subset of the problem that is going to be explored in this session. One useful tool is to
find all of the nouns and verbs in the problem statement. The nouns are a good key to
what class are in the system, and the verbs show what there responsibilities are going to
be.
51