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 card 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.

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.

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 Cards in Design Development

1. Work using role play. Different individuals are different objects.

2. Pick a use case to building a scenarioto hand simulate.

3. Start with the person who has the card with the responsibility to initiate the use case.

4. In discharging a responsibility card owner may only talk to collaborators for that responsibility.

5. Gaps must be repaid and re-tested against the use case.

CRC Session

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 four types of people participate in the crc session. They are

1 . Domain Users

The Domain Users are the users of the system being designed. They should have good amount of business knowledge about the system which is being modeled.

2 . OO Design Analyst

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques. Their responsibilities on the project are well beyond the CRC modelling sessions.

3 . Facilitator

Facilitator is the one who is responsible to keep the crc session progress forward. This member is responsible to make sure that the team session conforms to the agenda.

4 . 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.

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.

Example

Problem Statement :

Our aim is to design an airline self check in system.

• A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
• Kiosk should be able to start a new session when the booking reference number 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 exist corresponding to the scanned passport by connecting to the database.
• The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database 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 bags 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 bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
• Boarding pass dispenser should be able to print the 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 class
• Display Console
• Baggage check in controller
• Boarding pass dispenser
• Card swipe

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 : scan the bar code on the passport and should be able to query the reservations database
• Database class : should be able to process the query and transfer the results
• Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
• Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
• Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
• Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

Discovery of Collaborations

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

Kiosk

• The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.

Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]

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 that number in the reservations database. So the scanner class should have a collaboration with the db class. 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 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 db class. So it should have a collaboration with the db class. 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]

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 bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.

Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]

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 the information to the kiosk that the session has been completed so that it can start a new session.

Collaborators : [Display console, Scanner, Kiosk]

References

[1]

[2]

[Object oriented programming using Java by Simon Kendal]

[Object Oriented Thought Process by Matt Weisfeld]