CRC Technique

CRC technique can also be used to find the domain objects and services. CRC stands for Class-Responsibility-Collaborator. Let's now see how to identify objects using CRC Technique.

Responsibility-Driven Design is a technique that can be used to identify objects. Responsibilities become attributes and operations after we refine our model. This technique is very helpful to teach beginners about OOAD. Once you become familiar with this approach it becomes easy to think in terms of objects and collaborations. Consequently, developers will be able identify objects mentally.

This can be used during both the analysis and design phases. The emphasis will shift from what to how when we move from analysis to design. So, the CRC cards will be different for these two phases.

In order to make it easier for the reader to understand the CRC technique, we will use a mini-case study to illustrate the concepts. The emphasis will be on identifying objects and we will make simplifying assumptions to make it easier to swiftly move to implementation stage. This means we will not have any realistic non-functional requirements, legacy constraints etc. Let's now look at a case study.

Customer Credit Card Account Management Program

System Description

The program facilitates a credit card customer service representative (CSR) to maintain and access information about credit cards of the customer. Credit card type, holder’s name, credit card number and expiration date describe each credit card. Customer needs access to their credit card related information such as account balance, available credit, last payment date, last payment amount, any current minimum amount due, due date, past due amount if any. Data is saved in XML format.

A CSR can run the program by logging on using their user id and password. This is due to the need for knowing who made changes or notes on a customer’s credit account. Notes are made to record notification of late payment by the customer, request for credit line increase, report of lost or stolen credit card, report of unauthorized charges, dispute related information etc. Once the CSR logins into the system, they can pull up the customer related information by entering the credit card number and doing search to get the related information. The screen shows customer’s authentication information such as their social security number, security question and answer and date of birth. A CSR must authenticate the customer before making any modifications or giving out any information related to that particular customer account. Customer record includes their current address, contact number and account holder name.

Let us now move on from the initial specification to writing main success scenario for most frequently used use cases. We will defer the alternative path related work to the next iteration. The interaction between the system and the actor will be documented in a user interface intensive terms at a high level of abstraction. This is because we will know what data is going into and out of the system. This is a short-cut that we are taking for the purpose of our case study. In reality the users and domain experts will provide input on what information they will be providing and expecting from the system.

We have selected Record Dispute as the most frequently used use case because we are making the assumption that the use cases that are most frequently used are Retrieve type of use case and this information can be given by the automated system over the phone. The phone interface is not capable of handling dispute charges. Our program therefore will focus more on functionality provided to the CSRs. CSR is capable of resolving the dispute and in some cases provide immediate resolution in favor of the customer depending on the situation.

Scenarios

Scenario 1 CSR selects “Record Dispute” from the menu.

High-level interaction

CSR selects “Record Dispute” from the menu.
System displays a new screen that can capture all the dispute related information.
Customer provides the merchant name, transaction amount, transaction date and the reason for dispute. CSR enters this information into the system and saves it.

Scenario 2 : Customer wants to update address.

High-level interaction

CSR pulls up the account information related to the customer by searching on the account number. The customer record contains social security number, date of birth, current address and the security question
CSR requests the customer to identify himself and checks the information with that of the system. CSR selects change address.
System prompts for new address.
CSR enters the new address and updates the system.

We will use the above two scenarios to illustrate the CRC technique.

Identifying Candidate Classes

Let us use parts of speech technique to find the candidate classes. Underline the nouns and noun phrases in the specification document to get a list of potential classes. Merriam-Webster dictionary defines noun as any member of a class of words that typically can be combined with determiners to serve as the subject of a verb, can be interpreted as singular or plural, can be replaced with a pronoun, and refer to an entity, quality, state, action, or concept

Step 1 - Identify candidate classes from specification document. The candidate classes are in bold in the following specification document.

The program facilitates a credit card customer service representative (CSR) to maintain and access information about credit cards of the customer. Credit card type, holder’s name, credit card number and expiration date describe each credit card. Customer needs access to their credit card related information such as account balance, available credit, last payment date, last payment amount, any current minimum amount due, due date, past due amount if any. Data is saved in XML format.

A CSR can run the program by logging on using their user id and password. This is due to the need for knowing who made changes or notes on a customer’s credit account. Notes are made to record notification of late payment by the customer, request for credit line increase, report of lost or stolen credit card, report of unauthorized charges, dispute related information etc. Once the CSR logins into the system, they can pull up the customer related information by entering the credit card number and doing search to get the related information. The screen shows customer’s authentication information such as their social security number, security question and answer and date of birth. A CSR must authenticate the customer before making any modifications or giving out any information related to that particular customer account. Customer record includes their current address, contact number and account holder name.

Step 2 – Identify candidate classes from scenarios.

Parts of speech technique has the draw back of looking at only the specification for the candidate classes. We will miss classes that will be required for implementation if we do not look at other sources. Therefore let us look for candidate classes in our scenarios as well.

Scenario 1: CSR selects Record Dispute from the menu.

High-level interaction:

CSR selects Record Dispute from the menu.
System displays a new screen that can capture all the dispute related information.
Customer provides the merchant name, transaction amount, transaction date and the reason for dispute. CSR enters this information into the system and saves it.

Scenario 2: Customer wants to update address.

High-level interaction:

CSR pulls up the account information related to the customer by searching on the account number. The customer record contains social security number, date of birth, current address and the security question
CSR requests the customer to identify himself and checks the information with that of the system. CSR selects change address.
System prompts for new address.
CSR enters the new address and updates the system.

Step 3 – Create Candidate Class List

Candidate Classes

Credit card
Customer service representative
Customer
Credit Card type
Holder’s name
Credit card number
Expiration Date
Account Balance
Available Credit
Last Payment Date
Last payment amount
Current minimum amount due
Due date
Past due amount
User id
Password
Credit Account
Notes
Credit Line
Social Security Number
Security Question
Security Answer
Date of birth
Current Address
Contact Number
Account Holder Name
Record Dispute
Merchant Name
Transaction Amount
Transaction Date
Dispute Reason
Account Number
Account
New Address

We have combined the candidate classes from the specification and the scenarios. We have also eliminated any duplicate entries in our list. Now we are ready to move on to the next step, which is filtering the candidate classes to find the final list of classes.

Step 4 – Triage the Candidate Classes

Let us now go through our selection of nouns and check if they can be moved from a candidate class list to required class list.

Credit card. The Credit card consists of account holder’s name, credit card number, expiration date and credit card type. We need this class for implementation therefore we will move this to our class list.
Customer service representative. This is just an actor. Is this part of our system? Does the system keep track of anything related to CSR? The answer is yes, but only for the purposes of keeping track of who made changes or added notes to a customer account. We will keep this class.
Customer. We maintain the customer information in the system. These are cardholder’s name, current address, date of birth, social security number and credit card number owned by the customer. We will implement this as a class.
Credit Card type. This is just a String (Master Card, Visa, Amex, Discover etc) and is an attribute that belongs to Credit card class that we discovered above.
~~Holder’s name~~. This is the same as the Account Holder’s name listed below.
Credit card number. This is a number that can be represented as an Integer. It is an attribute that belongs to Credit Card class.
Expiration Date. This is a Date object and is an attribute that belongs to Credit Card class.
Account Balance. This is a number and can be represented by a real number. This is an attribute of Credit Account class (listed below in this list).
Available Credit. A real number represent amount of credit available. It is another attribute of Credit Account class.
Last Payment Date. A Date is an object and is an attribute of Last Payment class. Last Payment will be a new class that will hold all the information related to the previous statement.
Last payment amount. A real number and an attribute of Last Payment class.
Current minimum amount due. A real number and an attribute of Current Payment class (a new class to hold all the relevant attributes and behavior).
Due date. A Date object and an attribute of Current Payment class.
Past due amount. A real number and an attribute of Current Payment & Last Payment class.
User id. This is a String and is an attribute that belongs to Login Account used by CSR to login to the system.
Password. Same as above.
Credit Account. This is an important concept and must be implemented as a class. This will hold all the data and behavior associated with the credit card account of the customer.
Notes. This is String object holding the information related to the communication between the CSR and the customer. Unknown during first pass on this list. After the first pass is made on this list we have made a decision to let this be part of Record Dispute class (which is below).
Credit Line. A real number that belongs to the Credit Account class discovered above.
Social Security Number. A number that is an attribute of the Customer class.
Security Question. A String that is an attribute of some class. We don’t know what it will be yet. We might define a Authenticate or Identify class.
Security Answer. Same as above.
Date of birth. A Date class and is an attribute of Customer class.
Current Address. This is a class by itself; we will implement a class called Address that will have street name, zip, city and state attributes. This is required due to the application requirements.
Contact Number. An Integer that is an attribute of Customer class.
Account Holder Name. A String that is an attribute of Credit Card class.
Record Dispute. This is a class that will have all the data and behavior related to the dispute.
Merchant Name. A String that is an attribute of Record Dispute class.
Transaction Amount. A real number and an attribute of Record Dispute class.
Transaction Date. A Date object and an attribute of Record Dispute class.
Dispute Reason. A String that is an attribute of Record Dispute class.
~~Account Number~~. This is the same as the Credit Card Number. We will combine the two names representing the same concept with just one name, Credit Card Number. Therefore, this is eliminated.
Account. This concept is already captured by Credit Account. We will eliminate this candidate class from the list.
New Address. This is the same type as Address that we have already discovered. So, we don’t need a new class to implement this concept.

Step 5 – Required Class List

We now have the following list of classes that we need to design and implement in our system.

Credit card
Customer service representative
Customer
Last Payment
Current Payment
Credit Account
Address
Record Dispute

Step 6 – List of Attributes Identified During the Triage of Candidate Classes

Credit Card type. Credit card class
Credit card number. Credit Card class.
Expiration Date. Credit Card class.
Account Balance. Credit Account class
Available Credit. Credit Account class.
Last Payment Date. Last Payment class.
Last payment amount. Last Payment class.
Current minimum amount due. Current Payment class
Due date. Current Payment class.
Past due amount. Current Payment & Last Payment class.
User id. Login Account class.
Password. Login Account class.
Notes. Record Dispute class.
Credit Line. Credit Account class.
Social Security Number. Customer class.
Security Question. Authenticate or Identify class.
Security Answer. Same as above.
Date of birth. Customer class.
Contact Number. Customer class.
Account Holder Name. Credit Card class.
Merchant Name. Record Dispute class.
Transaction Amount. Record Dispute class.
Transaction Date. Record Dispute class.
Dispute Reason. Record Dispute class.

Step 7 – List of Attributes Categorized According to the Class where it belongs

Credit Account

Account Balance
Available Credit
Credit Line

Last Payment

Last Payment Date
Last payment amount
Past due amount

Current Payment

Current minimum amount due
Due date
Past due amount

User id
Password

Identify

Security Question
Security Answer

Credit Card

Account Holder Name
Expiration Date
Credit Card Number
Credit card type
Expiration Date

Record Dispute

Merchant Name
Transaction Amount
Transaction Date
Dispute Reason
Notes

Customer

Contact Number
Date of birth
Social Security Number

Step 8 – Identify Class Responsibilities

The functionality required by the system is described in the use cases. The classes that collaborate together will implement the functionality and each class will have some responsibilities that it carries out during this activity. We can expand the high-level interactions into collaborations between classes and document the responsibilities that emerge.

Each class will have a CRC card with the following information on it.

Class name
Attributes
Responsibilities
Collaborators
Short description of the purpose of the class

The short description is written on the back of the card. For instance for Credit Card class, it will be: "I maintain all the information related to Credit Card and provide any required operations on my data to my clients".

When you trace the use case scenarios with the CRC cards record all the information indicated above. During the trace if you find that you need a new class, we can create a new card for the new class and record the related information on it.

Scenario 1: CSR selects Record Dispute from the menu.

High-level interaction:

CSR selects “Record Dispute” from the menu.
System displays a new screen that can capture all the dispute related information.
Customer provides the merchant name, transaction amount, transaction date and the reason for dispute. CSR enters this information into the system and saves it.

Class-level interaction:

CSR select “Record Dispute” from the menu.
Record Dispute UI is displayed on the screen.
Record Dispute Controller saves the Credit Account and the corresponding Record Dispute in the system.

As we work at a lower level of abstraction we find that we must associate an account to a dispute. Otherwise we will not know which customer filed a dispute. We also have discovered that we need a new class called Record Dispute Controller. This class hooks up the UI to the domain classes Credit Account and Record Dispute. Let us now document the responsibilities on the CRC cards.

Class: Record Dispute Controller

Responsibilities:

To respond to the user-interface events.
To delegate work to the appropriate domain classes.
To display the results to the user.

Collaborators:

RecordDisputeUI
CreditAccount
RecordDispute

Back of the card:

Description: I am the use case controller responsible for connecting the user interface to the domain classes. I encapsulate control logic.

Attributes: Let us leave this blank for now. We do not need to be exhaustive while filling out the CRC card. We must avoid analysis paralysis.

CRC card format

Front of the CRC card

CRC Front

Back of the CRC card

CRC Back

You can think of a CRC card with the front as the public view and the back as the private view with implementation details. The CRC should contain Class name, Responsibilities and Collaborators section as the minimum. Attributes are considered implementation details and must be shown on the back of the card.

Class: Record Dispute

Responsibilities:

Create a dispute record in the system.
Provide access to existing dispute record.

Collaborators: Record Dispute UI

Description: I maintain all the information related to dispute and provide any required operations on my data to my clients

Attributes:

Merchant Name
Transaction Amount
Transaction Date
Dispute Reason
Notes

Note: We can rename the RecordDispute to DisputeRecord (verb phrase is changed to noun phrase due to the naming convention for classes).

Scenario 2: Customer wants to update address.

High-level interaction:

CSR pulls up the account information related to the customer by searching on the account number. The customer record contains social security number, date of birth, current address and the security question
CSR requests the customer to identify himself and checks the information with that of the system. CSR selects change address.
System prompts for new address.
CSR enters the new address and updates the system.

Class-level interaction:

CSR enters account number of the customer and does a search for the account.
Credit Account UI detects the user-interface search event and delegates the search functionality to Credit Account Manager class.
Credit Account Manager searches to find the account information corresponding to the account number of the customer.
Credit Account Manager returns the Credit Account class.
Credit Account UI queries the Credit Account class for the required fields and displays the information.
CSR selects the change address from the menu.
Credit Account UI responds to the change address user-interface event and prompts for new address.
CSR enters the new address and clicks update address. Credit Account UI sends the new address data and delegates the update operation to the Account Manager class.
Account Manager class updates the system with the new address.

Class: Credit Account UI

Responsibilities:

Provide the UI for the credit account related information.
Delegate work to the Credit Account Manager class.

Collaborators:

Credit Account Manager
Credit Account

Description: I provide the user interface to the credit account information and delegate all the functionality to a controller class.

Attributes: none (for now)

Class: Credit Account Manager

Responsibilities:

Provide access to the existing credit account information.
Provide search by account number functionality to find credit account.

Collaborators:

Credit Account UI
Credit Account

Description: I encapsulate the control logic for searching and retrieve account related data used by my clients.

Attributes: none (for now)

Class: Credit Account

Responsibilities:

Provide access to the credit account information.

Collaborators:

Credit Account Manager
Credit Account

Description: I provide the data and access to the credit account related information to my clients.

Attributes:

Account Balance
Available Credit
Credit Line

We can repeat the procedure outlined above to all other scenarios. Once we have a complete set of CRC cards documented we need to verify that each class is capable of providing the functionality documented in the scenarios. If we had missed any responsibility then we need to add them. If there are responsibilities that are not required then it must be removed from the classes.

The main advantage of the CRC cards is their flexibility. It is very easy to move the CRC cards around to see how they collaborate and make changes to the CRC cards. This is very much like Agile Modeling. This technique is extremely useful during the analysis phase when the requirements are fluid. During the design phase we can add more details to the CRC cards such as define the data types of the attributes, include classes to satisfy non-functional requirements etc. Keep in mind that we work with cards that are limited in size and we may not prefer to work with CRC cards during the design phase at all.

The real question is Where does the CRC technique fit in the big picture? The answer is that they find their use in modeling the vocabulary of the system. In other words, CRC cards in conjunction with use case-based analysis can aid us in the discovery of abstractions in both the problem and the solution domain. They are also used when we are modeling structural relationships. By using CRC cards in combination with use case analysis we can identify the classes that must interact. These interacting classes must have an association between them. Larman calls this as need to know associations. It is noteworthy to mention that CRC technique forces us to look at the structural and behavioral scenarios. This concludes our simple introduction to the CRC technique.