CRC Cards ConceptualOverview¡ An index card that is used to represent … ¡ A class ¡ the responsibilities of the class and ¡ the interaction between classes.¡ A creative approach to object oriented modeling.¡ The cards are created through scenarios based on the system requirements that model the behavior of the system.¡ The name CRC comes from Class, Responsibilities, and Collaborators which the creators found to be the essential dimensions of object oriented modeling.
History of CRC Cards ¡ Invented by Ward Cunningham and Kent Beck ¡ OOPSLA 1989 ¡ Originally a teaching tool for OO learners
Why use CRC cards?¡ Portable... No computers need. They can be used anywhere. Even away from the office.¡ They allow the participants to experience first hand how the system will work. No computer tool can replace the interaction that happens by physically picking up the cards and playing the role of that object.¡ They are useful for teaching people the object- oriented paradigm.¡ They can be used as a methodology themselves or as a front end to a more formal methodology such as USDP, RUP, Booch, Wirfs-Brock, or Jacobson.
Glossary¡ Class: The blueprint for an object.¡ Collaboration: The process whereby several objects cooperate to provide some higher-level behavior.¡ Object: Something that can do things. An object has state, behavior, and identity. The structure and behavior of similar objects are defined in their common class.¡ Responsibility: Some behavior for which an object is held accountable. A responsibility denotes the obligation of an object to provide a certain behavior.¡ Subclass: A class that inherits from one or more classes.¡ Superclass: The class from which another class inherits.
The Group¡ The ideal group size for a CRC card session is five or six people.¡ In groups of larger size the productive is cut by more disagreements and the amount of participation by everyone is lower.¡ Who should be in the group? ¡ One object-oriented technology facilitator ¡ Two or three domain (business) experts, ¡ The rest should be developers
The Cards Class NameSuperclass:Subclasses: Responsibilities Collaborators
How do we identify classes?¡ 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.¡ Look at the use cases or requirements document.¡ Find the nouns. ¡ Nouns imply classes.¡ Use this information for the basis of a brainstorming session.¡ Write one class name at the top of each card.¡ Assign each class to a member of the group. ¡ He/she becomes the owner of that class for the session.
The Scenario¡ The team breaks the use cases into scenarios.¡ They focus on one scenario at a time.¡ The facilitator reads through the use-case scenario.¡ As an object is instantiated, the owner of that base class picks up his classʼ’s CRC card. ¡ As long as that class is ʻ‘aliveʼ’, the owner keeps the card in the air.¡ While reading through each line in the scenario, the team identifies ¡ Responsibilities ¡ Other classes ¡ How each class interacts with others.¡ The owner of that card writes the teamʼ’s findings on the card.¡ We keep doing this through each step and each scenario.
How do we identifyresponsibilities?¡ Some responsibilities are obvious from: ¡ The name of the class ¡ The use case description.¡ Others will be fleshed out as the team walks through scenarios. ¡ Most of those become obvious as well.¡ Find the verbs in the use cases. ¡ Verbs imply responsibilities.¡ You dont need to find them all (or any) before the scenarios. ¡ The advantage of finding some in the beginning is that it help provide a starting place.
How do we identifySuperclasses andSubclasses?¡ Superclasses and subclasses can be defined at any time they become obvious.¡ The scenarios will illuminate these as well.¡ It is up to the group to decided if they want to define any hierarchical relationships now or wait till the scenarios to do this.
How do we identifyattributes?¡ Attributes of the classes arenʼ’t really supposed to be identified during the CRC session. ¡ They are an implementation detail. ¡ Should go on the back of the card.¡ But if you really, really want to, go ahead.¡ Find the adjectives. ¡ Adjectives imply attributes.¡ The responsibilities of the class will help make these clear.¡ Attributes are general not defined at all until the design phase, but they can be defined at any time the group thinks it is appropriate.
How do we identifycollaborations?¡ Anytime a use case involves two or more classes, a collaboration exists.¡ Strong relationships exist when two or more classes are together in the same step of a scenario.
Conclusion¡ A fun, effective way to work through OO Analysis.¡ Makes the art of identifying classes, responsibilities (methods), and collaborations simple.