Extract Classes from Problem Description

Assume you have selected a (functional) requirement of your software to implement. Focus on the description of that requirement to extract classes. We will use a fairly simple method to address this task, which serves well for most software problems. It involves:

• Using the verb/noun method to discover initial classes.
• Using CRC cards to discover the responsibilities (behaviors) of each class and the collaboration (relationships) between them.

The verb/noun method

Read through the description of a requirement, looking for nouns that represent objects in the problem domain. These nouns represent the simplest candidates to be classes. Moreover, actions that determine classes' behavior often reveal themselves as verbs.

For example, suppose we were to implement an app for the CS students to review the courses we offer. Consider the requirement:

• As a JHU CS student, I want to search for and select a CS course I've taken so that I can write a review for it.

The nouns "Student," "Course," and "Review" are candidates for classes. The verbs "select" (a course) and "write" (a review) are candidates for the methods (behavior) shared among (the nominal) classes.

The verb/noun method is a gateway to your design. However, be mindful that not all nouns nor all verbs correspond to classes/behaviors. Moreover, not all potential entities are discoverable using this strategy. As you design your software, you might find that you need a few additional classes or that some of the classes extracted at this stage are not needed.

Aside: Conventionally, the names of classes are singular rather than plural. This is because multiplicity is achieved by creating multiple instances of a class.

The CRC Model

A Class Responsibility Collaborator (CRC) model¹ is a collection of standard index cards that have been divided into three sections, as depicted below.

Here is an example of a CRC card for the aforementioned User Story.

A responsibility is something that a class knows or does. Often a class has to collaborate with other classes to fulfill a responsibility. Collaboration usually takes one of two forms: a request for information or a request to do something.

Aside: CRC model was originally used as a teaching technique but found its way to the software engineers' arsenal as an effective modeling tool.

CRC Session

The goal of a CRC session is to discover classes and convert them to CRC cards. It is recommended to do this in a group setting to foster discussion and brainstorming.

The session involves iteratively performing the following steps:

• Pick a functional requirement (written as a User Story).
• Extract classes.
• Find responsibilities.
• Define collaborators.
• Refine responsibilities/collaborators of other entities if needed!

A session should focus on a fairly small and manageable portion of the system at a time. The best is to focus on the subset of requirements that will be implemented in the next iteration.

The outcome of a CRC session, like that of the verb/noun method, is not carved in stone! When you get to implement the model, new classes will be introduced, responsibilities will be reorganized, existing classes will disappear, and so on.