CSC/ECE 517 Fall 2010/ch1 S6 CC

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

Introduction

CRC stands for Class Responsibility Collaborator. CRC cards modeling is one of the venerable Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system. Class, Responsibilities and Collaborators are recorded on index cards to facilitate team-based role play.

Class-Responsibility-Collaboration cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking" as a way to help beginners learn object oriented design. More recently, the technique has become regarded useful beyond teaching because of the subtle way it supports critical characteristics of design. CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

The CRC card technique has three basic strengths. The three strengths are:

• CRC cards facilitate open discussion of static structure of system.

• CRC cards have built-in heuristics that guide design, in the name of determining the Class name, the Responsibilities, and the Collaborators.

• CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.

Structure of a CRC card

CRC cards explicitly represent multiple objects simultaneously. CRC card components are explained as follows:

Class Name

The class name appears across the top of the card. The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand.

Class Responsibilities

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

Class Collaborators

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

Structure of a CRC Card

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

CRC Modeling

A CRC Model is a collection of CRC cards that represent whole or part of an application or problem domain. The degree of collaboration between any two classes in the model determines the relative placement of their corresponding cards in the model. Cards that collaborate with one another are placed close to each other, cards that don't collaborate are not placed near each other.

CRC Model of NCSU Libraries System

CRC Modeling is an iterative process. In a nutshell, CRC Modeling comprises of the following steps :

1. Creating a CRC Modeling team
2. Brainstorming
3. Iteratively perform the steps of CRC Modeling
4. Perform use-case scenario testing

Creating a CRC Modeling team

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally five types of people participate in the CRC session. They are:

Business Domain Experts (BDEs)

The Business Domain Experts (BDEs) are the real users of the application system. These are the people who have the complete business knowledge about how the application works day in and day out. There are typically four or five BDEs involved in CRC modeling. If there are not enough BDEs then the team might not have wide enough range of knowledge and experience. And, if there are more than five people involved in the team we will find that they might get in each others way. So, it is very essential that we pick the right amount of people for our team.

Good BDEs should be possessing excellent communication skills, wide range of business knowledge and should be able to think clearly and logically.

Design Analyst

Design Analysts are the ones who are familiar with the Object-oriented methodologies and techniques. Their responsibilities on the project are well beyond the CRC modelling sessions. These may include fleshing out the CRC cards to create a formal object model, and interpreting the CRC collaborators to document the OID's (Object Interaction Diagrams)

Good design analyst should be very experienced in developing Objected-oriented systems and should clearly understand the CRC modeling and methodologies and Object-oriented modeling and methodologies.

Facilitator

Facilitator is the most important member of the team. This person runs the CRC session.

This person is responsible to keep the CRC session progressing forward and to make sure that the team sessions conform to the agenda. Facilitator maintains the status of the CRC Modeling process from session to session and leads the team towards completion of the CRC Modeling phase.

Good Facilitator should possess good meeting skills, clearly understand the CRC modeling and methodologies and Object oriented modeling and methodologies.

Scribe

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards. This documentation is often used to rollback the system into requirements and business case documents.

Scribes must have good oral and written communication skills, and should have good ear for business logic.

Observer

For training purposes, one may wish to have one or more people sit in on the CRC modeling session as observers. Observers sit at the back of the meeting room and do not participate in the discussions but just observe.

Brainstorming

Brainstorming is the phase in which the modeling team will try to identify and understand the requirements of the application system they are designing. It is more of an Idea-generation technique rather than an Idea-evaluation technique. Using the brainstorming process, the team members build on ideas of each other.

Some of the potential questions in a brainstorming session which could generate ideas are as follows :

• Who is this system for?

• What are the customer or business needs and requirements of the system?

• How can we do this better?

• What are the skills or knowledge to be possessed by the customer in order to use the system?

• Is there any training required for the customers?

• How can we do this faster and cheaper?

Iteratively perform the steps of CRC Modeling

BDEs are heavily involved in this particular phase of CRC Modeling. The CRC model, comprising the CRC cards are filled out on a large table, while the whole team spends time discussing the system. BDEs will try to get better feel of the overall application, by standing or sitting around the table, so that they can get a bird's eye view of their model.

The steps of CRC Modeling are as follows:

Discovery of Class names

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities.

For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement.

This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

Discovery of Class responsibilities

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements.

Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities.

If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

Discovery of Class Collaborations

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with.

We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities.

At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

Moving the cards around

This phase involves moving the cards around, such that team members will be able to identify relationships and associations between the corresponding classes and help them to understand the application system better.

Cards that collaborate with each other should be close one another on the desk. The more the two cards collaborate with each other, the closer they should be on the desk.

Cards which are highly associated to several cards should be placed at the center. These are called "busy" cards.

Perform Use-Case scenario testing

It is a task process pattern in which users are actively involved with insuring that user requirements are accurate. The basic idea is that a group of Business Domain Experts (BDEs), with the aid of a facilitator, step through a series of defined use cases to verify that CRC model accurately reflects their requirements. The facilitator distributes the cards to the BDEs, trying to ensure that two cards that collaborate are given to two different people. The facilitator then leads the group through acting out each scenario one at a time.

In this process, we can more accurately determine the responsibilities of each class and update the cards whenever necessary. As the BDEs describe the business logic of the responsibility, they will often describe a step where they need to collaborate with another card to complete.

This particular phase is also known as "Role play".

Airline Self Check-In Kiosk(Example)

Problem Statement

Our aim is to design an Airline Self Check-In system.

• A Self Check-In Kiosk at the airport consists of Passport scanner, Display console, Baggage Check-In controller, Database Controller, Boarding pass dispenser and Card Swipe reader.
• Kiosk should be able to start a new session when the "Booking reference number" /PNR is typed in or, passport is scanned. It should provide access to component parts for each session
• The Passport scanner should be able to scan the bar code on the passport and check if any record exists corresponding to the scanned passport by connecting to the database.
• The Display console should provide a touch based console to accept the entered airline "Booking reference number". It should be able to pass the query onto the reservations database using the Database controller and display the result. Based on the result it should also be able to provide access to the baggage check-in system.
• Baggage Check-In controller should provide a count for the maximum number of Check-In baggages allowed based on the data retrieved by scanning the passport, and should also be able to weigh the bag, and check if the weight of the baggage is in the allowed limit or not. It should also provide an option for the user to check-in extra baggages if he/she wants to. Based on the number of extra baggages entered by the user, it should calculate the required amount.
• Boarding pass dispenser should be able to print boarding passes and should pass the message to the Kiosk to start a new session.

Discovery of Classes

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

• Kiosk
• Passport scanner
• Database controller
• Display Console
• Baggage Check-In controller
• Boarding pass dispenser
• Card swipe reader

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But, by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

Discovery of Responsibilities

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

• Kiosk : should be able to start a new session and provide access to component parts.
• Passport scanner : should scan the bar code on the passport and should be able to query the reservations database.
• Database controller: should be able to process the query and transfer the results.
• Display console : should be able to accept the booking reference number from the customer, query the reservations database, display the result.
• Baggage Check-In controller : should count the maximum number of allowed baggages, weigh each baggage, beep if a particular baggage exceeds limit, pass baggages to the airport personnel, facilitate the customer to check in additional baggage.
• Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass a message to the Display console that the session has ended, after all the boarding passes have been dispensed.
• Card swipe reader: should scan the magnetic strip on the card, send the user's bank account credentials to the Bank database connections.

Discovery of Collaborators

Our next step is to discover all the collaborations that exist in the system. In order to discover relations between different classes, we need to use various use cases. We will deal with each event step by step.

Kiosk

• The Kiosk comprises of the whole Airline Self Check-In system. This system consists of components like Scanner, Display console etc. Kiosk is the class that provides access to all these sub-classes. So, it should have collaborations with all immediate components.

Collaborators : [Scanner, Display console, Database controller, Baggage Check-In controller, Boarding pass dispenser, Card swipe reader]

Passport Scanner

• As the user scans his/her passport, the scanner should recognize the passport number, and check if there is a reservation corresponding to the scanned passport in the reservations database. So, the scanner class should have a collaboration with the Database controller. It should also pass the necessary information to the Baggage Check-in controller, for example : maximum number of bags that can be allowed.

Collaborators : [Database controller, Baggage Check-In controller]

Display Console

• Instead of scanning the passport, the user may also enter the PNR or reference number through the Display console. The Display console should check if there is any reservation corresponding to that reference number by connecting to the Database controller. So, it should have a collaboration with the Database controller. It should also pass the necessary information to the Baggage Check-In controller, for example : maximum number of baggages that can be allowed.

Collaborators : [Database controller, Baggage Check-In controller]

Baggage Check-In controller

• Baggage Check-In controller receives the information from either the display console or the scanner and should update its count. As the user passes that baggages, it weighs the baggages and beeps if any of them crosses the weight limit. It also provides an option to the user if he/she wants to check in extra baggages. Based on the number of extra baggages, it calculates the amount to be received and prompts the user to swipe his/her credit/debit card. As the user swipes the card, the controller authenticates with the Bank connection and deducts the required amount. So, it should also collaborate with the Database controller.

Collaborators : [Database Controller, Card swipe reader, Passport scanner, Display console, Boarding pass dispenser]

Boarding pass dispenser

• After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends a message to Display console and Kiosk that the session has been completed and it can start a new session if needed.

Collaborators : [Display console, Scanner, Kiosk]

Advantages

There are many advantages to CRC Modeling :

• The people who understand the problem domain, the business domain experts (BDEs) are the people who create the model.

• Users and developers work together side-by-side to create the CRC model.

• This technique is very inexpensive and portable. Buying and maintaining index cards is very easy.

• The approach is simple and straightforward. Does not need any complex equipment or even a computer for this in fact.

• CRC Modeling and Prototyping are both iterative processes in which users are greatly involved.

• Because users are actively involved in designing the application, their satisfaction with work is much greater.

Conclusion

CRC Modeling is very effective technique for identifying and user requirements. As illustrated by the above advantages, it would be greatly beneficial to include CRC Modeling in the Software Development Life Cycle. This technique works hand in hand with use cases and prototypes and leads directly to class modeling.

References

A laboratory for teaching object oriented thinking [1]

Introduction to CRC Models [2]

Object Oriented Thought Process [3]

Validation CRC Cards [4]

Reflections on CRC Cards [5]

CRC Modeling: Bridging the communication gap between the developers and users [6]