CSC/ECE 517 Fall 2010/ch1 S6 CC: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(78 intermediate revisions by the same user not shown)
Line 3: Line 3:
= '''Introduction''' =
= '''Introduction''' =


'''CRC''' stands for '''Class Responsibility Collaborator'''.[http://en.wikipedia.org/wiki/CRC_cards 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.
CRC stands for Class Responsibility Collaborator. [http://en.wikipedia.org/wiki/CRC_cards 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 [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] and [http://en.wikipedia.org/wiki/Ward_Cunningham 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.
Class-Responsibility-Collaboration cards have been first introduced by [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] and [http://en.wikipedia.org/wiki/Ward_Cunningham 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:
The CRC card technique has three basic strengths. The three strengths are:


* CRC cards facilitate open discussion of static structure of system.
* CRC cards facilitate open discussion of static structure of system.
Line 15: Line 15:
* CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.
* CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.


== Structure of a CRC card ==
= '''Structure of a CRC card''' =


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


'''Class Name'''
=='''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.  
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'''
=='''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.  
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.  
Line 29: Line 29:
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.
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'''
=='''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.
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.


[[Image:CRC.png]]
[[Image:CRC_new.jpg|thumb|center|480x500px|alt=Structure of a CRC Card|Structure of a CRC Card]]


[[Image:crc_2.jpg]]
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.
 
[[Image:CRC_model.jpg|thumb|center|616x626px|alt=CRC Model|CRC Model of [http://www.lib.ncsu.edu/ 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 <br />
2. Brainstorming <br />
3. Iteratively perform the steps of CRC Modeling <br />
4. Perform [http://en.wikipedia.org/wiki/Use_case use-case] scenario testing <br />
 
== '''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 [http://en.wikipedia.org/wiki/Business_domain 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''' ===
 
[http://en.wikipedia.org/wiki/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''' ==
 
[http://en.wikipedia.org/wiki/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?


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


== CRC Cards in Design Development ==
The steps of CRC Modeling are as follows:


1. Work using role play. Different individuals are different objects.
=== '''Discovery of Class names''' ===


2. Pick a use case to building a scenarioto hand simulate.
The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities.  


3. Start with the person who has the card with the responsibility to initiate the use case.
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.  


4. In discharging a responsibility card owner may only talk to collaborators for that responsibility.
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.


5. Gaps must be repaid and re-tested against the use case.
=== '''Discovery of Class responsibilities''' ===


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


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
Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities.  


1 . '''Domain Users'''
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.  


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.
=== '''Discovery of Class Collaborations''' ===


2 . '''OO Design Analyst'''
To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with.  


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


3 . '''Facilitator'''
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.


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.
=== '''Moving the cards around''' ===


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


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


== Discovery of Class names ==
Cards which are highly associated to several cards should be placed at the center. These are called "busy" cards.


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.
== ''' Perform Use-Case scenario testing''' ==


== Discovery of Class responsibilities ==
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.


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


== Discovery of Class Collaborations ==
This particular phase is also known as "Role play".


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 ==
= '''Airline Self Check-In Kiosk(Example)''' =


Problem Statement :
== '''Problem Statement''' ==


Our aim is to design an airline self check in system.  
Our aim is to design an Airline [http://en.wikipedia.org/wiki/Self_check-in 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.
* A Self Check-In [http://en.wikipedia.org/wiki/Kiosk 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 is typed in or passport is scanned. It should provide access to component parts for each session
* Kiosk should be able to start a new session when the "Booking reference number" /[http://en.wikipedia.org/wiki/PNR 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 exist corresponding to the scanned passport by connecting to the database.
* 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 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.
* 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 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.
* 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 the boarding passes and should pass the message to the Kiosk to start a new session
* 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'''
== '''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 -
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 -
Line 102: Line 168:
* Kiosk
* Kiosk
* Passport scanner
* Passport scanner
* Database class
* Database controller
* Display Console
* Display Console
* Baggage check in controller
* Baggage Check-In controller
* Boarding pass dispenser
* Boarding pass dispenser
* Card swipe  
* 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.
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'''
== '''Discovery of Responsibilities''' ==


Our next step is to identify the responsibilities of each class listed above.
Our next step is to identify the responsibilities of each class listed above.
Line 117: Line 183:


* Kiosk : should be able to start a new session and provide access to component parts.
* 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
* Passport scanner : should 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
* Database controller: 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.
* 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 : 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
* 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 the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* 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 : 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.
* 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.


'''Discovery of Collaborations'''
=== '''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.


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.
Collaborators : [Scanner, Display console, Database controller, Baggage Check-In controller, Boarding pass dispenser, Card swipe reader]


'''Kiosk'''
=== '''Passport Scanner''' ===
* 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.
* 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 : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]


'''Passport Scanner'''
Collaborators : [Database controller, Baggage Check-In controller]
* 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'''
=== '''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.
* 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'''
Collaborators : [Database 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]
=== '''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.


'''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]
Collaborators : [Display console, Scanner, Kiosk]


== References ==
= '''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 [http://en.wikipedia.org/wiki/Index_card 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 [http://en.wikipedia.org/wiki/Prototyping 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 [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle 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 [http://c2.com/doc/oopsla89/paper.html]
A laboratory for teaching object oriented thinking [http://c2.com/doc/oopsla89/paper.html]
Line 159: Line 250:


Reflections on CRC Cards [http://docs.google.com/viewer?a=v&q=cache:Gr4Mr1ikWpsJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.19.1780%26rep%3Drep1%26type%3Dpdf+reflections+on+crc+cards&hl=en&gl=us&pid=bl&srcid=ADGEESir4Rn7b1jTiFXMoXoPzk14achFX53AWQAF9dq-ofgFshmQd2NTZfeemJvXY65cmdd4iadq4eGt-mVEQQFSZTEXUAKfsIgyyq0Tdm9YmqIuZPsUp4me-tLEaFqRqBDqrI9RkO9H&sig=AHIEtbQHNp64PIKYACq48_b7E9RgCHximg]
Reflections on CRC Cards [http://docs.google.com/viewer?a=v&q=cache:Gr4Mr1ikWpsJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.19.1780%26rep%3Drep1%26type%3Dpdf+reflections+on+crc+cards&hl=en&gl=us&pid=bl&srcid=ADGEESir4Rn7b1jTiFXMoXoPzk14achFX53AWQAF9dq-ofgFshmQd2NTZfeemJvXY65cmdd4iadq4eGt-mVEQQFSZTEXUAKfsIgyyq0Tdm9YmqIuZPsUp4me-tLEaFqRqBDqrI9RkO9H&sig=AHIEtbQHNp64PIKYACq48_b7E9RgCHximg]
CRC Modeling: Bridging the communication gap between the developers and users
[http://www.uml.org.cn/UMLApplication/pdf/crcModeling.pdf]

Latest revision as of 02:22, 18 September 2010

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
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
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]