The ideal group size for a CRC card session is five or six people. This size generally allows everyone to productively participate. In groups of large size the productive is cut by more disagreements and the amount of participation by everyone is lower. If there are more than six people, one solution is to have the extra people be present strictly as observers.
The group five or six people in the core group should be composed of developers, domain experts, and an object-oriented technology facilitator. In the initial Analysis phase there should be two or three domain experts, one object-oriented technology facilitator, and the rest of the group made up of people how are responsible for delivering the system. As the project moves more in to the design phase, some of the domain experts can be replaced with developers. There should always be at least one domain expert in the group to clarify an question that arise about the behavior of the system.
The cards should look something like this:
The exact format of the card can be customized to the preferences of the group, but the minimal required information is the name of the class, it's responsibilities and the collaborators. The back of the card can be used for a description of the class. During the design phase attributes of the class can be recorded on the back as well. One way to think of the card is the front as the public information, and the back as the encapsulated, implementation details.
Before starting a session there needs to be some kinds of requirements for the systems. Weather they are implicitly or explicitly define the people participating in the group need to be familiar with them. A session also needs to focus on one part of the problem at a time. So a subset of the problem needs to be chosen to explored during the CRC card session.
The first step in modeling an system in the object-oriented paradigm is to identify the class in the problem domain. So this is the first step in a CRC card session. Using the problem statement or requirements document, identify the classes that are obvious in the subset of the problem that is going to explored in this session. One useful tool is to find all of the nouns and verbs in the problem statement. The nouns are a good key to what class are in the system, and the verbs show what there responsibilities are going to be. Use this information for the basis of a brainstorming session and identify all the class that you see. Remember in a brainstorming session there should be no or little discussion of the ideas. Record them and filter the results after the brainstorming. After the classes have been chosen pass out cards and assign the class to the member of the group. Each person should be responsible for at least on class. They are the owner of that class for the session. Each person records the name of their class on a card. One class per card.
First decide which class is responsible for this function. The owner of the class then picks up his card. When a card is in the air it is an object and can do things. The own announces that he needs to fulfill his responsibility. The responsibility is refined in to smaller tasks if possible. These smaller tasks can be fulfilled be the object is appropriate or they can be fulfilled be interacting with other objects. If no other appropriate class exist, maybe you need to make one. This is the fundamental procedure of the scenario execution.
Lets move on the Analysis and try out first CRC card session.
Each borrower can be lent up to five items. Each type of library item can be lent for a different period of time (books 4 weeks, journals 2 weeks, videos 1 week). If returned after their due date, the library user's organization will be charged a fine, based on the type of item( books $1/day, journals $3/day, videos $5/day).
Materials will be lent to employees with no overdue lendables, fewer than five articles out, and total fines less than $100.
...(Design Constraints)...
With this problem statement identify the class and assign them to the group members. Make a card for each class.
Some ideas for class:
Now lets try our first scenario, taken from the requirement that the system bust allow users to check out lendables.
"What happens when Johny Codewarrior, who has no accrued fines and one outstanding book, not overdue, checks out a book entitle Document, Your job depends on it?"
"What happens when Johny Codewarrior returns the book Document, Your job depends on it two days late? He has no other item checked out and no acquired fines."
"What happens when Ivar Jacobson uses the search feature to look for the book Object-Oriented Software Engineering of which there are 2 copies available?"
"What happens when Grady Booch uses the search feature to look for the book Object-Oriented Analysis and Design with Application of which there is 1 copy available and the database is down?"
Redo the scenarios you did in the analysis phase, but know take in to consideration all of the design heuristics discussed. Make up your own scenarios and try them...