CRC Cards


Published on

Identifying classes from use cases using CRC Cards

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • CRC cards were introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for Teaching Object-Oriented Thinking" released in OOPLSA '89. There original purpose was to teach programmers the object-oriented paradigm. When Kent Beck wrote the draft version of their paper he changed Collaborators to helpers. Ward Cunningham changed it back to Collaborators when he reviewed the paper. The initials of Cunningham's son are CRC.
  • Although CRC cards were created for teaching, they have proven useful for much more. They become an accepted method for analysis and design. The biggest contributing factor to their success is the fact that they provide an informal and non threatening environment that is productive to working and learning.
  • These are terms used throughout this tutorial as defined by Grady Booch.
  • This size generally allows everyone to productively participate. If there are more than six people, one solution is to have the extra people be present strictly as observers. 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 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. So you might list attributes (properties) on the back.
  • Remember, for larger projects, we won’t be looking at the entire problem. Only a portion.
  • Always start with basic functionality at first. Only move on to advanced or optional functionality later. Examples: Error checking, non-essential, and so on.
  • Resist the temptation to get too far into the details.
  • CRC Cards

    1. 1. CRC Cards: An Overview
    2. 2. CRC Cards Conceptual Overview <ul><li>An index card that is used to represent … </li></ul><ul><ul><li>A class </li></ul></ul><ul><ul><li>the responsibilities of the class and </li></ul></ul><ul><ul><li>the interaction between classes. </li></ul></ul><ul><li>CRC cards are a creative approach to object oriented modeling. </li></ul><ul><li>The cards are created through scenarios based on the system requirements that model the behavior of the system. </li></ul><ul><li>The name CRC comes from Class, Responsibilities, and Collaborators which the creators found to be the essential dimensions of object oriented modeling. </li></ul>
    3. 3. Why use CRC cards? <ul><li>Portable... No computers need. They can be used anywhere. Even away from the office. </li></ul><ul><li>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. </li></ul><ul><li>They are useful for teaching people the object-oriented paradigm. </li></ul><ul><li>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. </li></ul>
    4. 4. Glossary <ul><li>Class: The blueprint for an object. </li></ul><ul><li>Collaboration: The process whereby several objects cooperate to provide some higher-level behavior. </li></ul><ul><li>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. </li></ul><ul><li>Responsibility: Some behavior for which an object is held accountable. A responsibility denotes the obligation of an object to provide a certain behavior. </li></ul><ul><li>Subclass: A class that inherits from one or more classes. </li></ul><ul><li>Superclass: The class from which another class inherits. </li></ul>
    5. 5. The Group <ul><li>The ideal group size for a CRC card session is five or six people. </li></ul><ul><li>In groups of larger size the productive is cut by more disagreements and the amount of participation by everyone is lower. </li></ul><ul><li>Who should be in the group? </li></ul><ul><ul><li>One object-oriented technology facilitator </li></ul></ul><ul><ul><li>Two or three domain (business) experts, </li></ul></ul><ul><ul><li>The rest should be developers </li></ul></ul>
    6. 6. The Cards Collaborators Responsibilities Subclasses: Superclass: Class Name
    7. 7. How do we identify classes? <ul><li>The first step in modeling an system in the object-oriented paradigm is to identify the class in the problem domain. </li></ul><ul><ul><li>So this is the first step in a CRC card session. </li></ul></ul><ul><li>Look at the use cases or requirements document. </li></ul><ul><li>Find the nouns . </li></ul><ul><ul><li>Nouns imply classes. </li></ul></ul><ul><li>Use this information for the basis of a brainstorming session. </li></ul><ul><li>Write one class name at the top of each card. </li></ul><ul><li>Assign each class to a member of the group. </li></ul><ul><ul><li>He/she becomes the owner of that class for the session. </li></ul></ul>
    8. 8. The Scenario <ul><li>The team breaks the use cases into scenarios. </li></ul><ul><li>They focus on one scenario at a time. </li></ul><ul><li>The facilitator reads through the use-case scenario. </li></ul><ul><li>As an object is instantiated, the owner of that base class picks up his class’s CRC card. </li></ul><ul><ul><li>As long as that class is ‘alive’, the owner keeps the card in the air. </li></ul></ul><ul><li>While reading through each line in the scenario, the team identifies </li></ul><ul><ul><li>Responsibilities </li></ul></ul><ul><ul><li>Other classes </li></ul></ul><ul><ul><li>How each class interacts with others. </li></ul></ul><ul><li>The owner of that card writes the team’s findings on the card. </li></ul><ul><li>We keep doing this through each step and each scenario. </li></ul>
    9. 9. How do we identify responsibilities? <ul><li>Some responsibilities are obvious from: </li></ul><ul><ul><li>The name of the class </li></ul></ul><ul><ul><li>The use case description. </li></ul></ul><ul><li>Others will be fleshed out as the team walks through scenarios. </li></ul><ul><ul><li>Most of those become obvious as well. </li></ul></ul><ul><li>Find the verbs in the use cases. </li></ul><ul><ul><li>Verbs imply responsibilities. </li></ul></ul><ul><li>You don't need to find them all (or any) before the scenarios. </li></ul><ul><ul><li>The advantage of finding some in the beginning is that it help provide a starting place. </li></ul></ul>
    10. 10. How do we identify Superclasses and Subclasses? <ul><li>Superclasses and subclasses can be defined at any time they become obvious. </li></ul><ul><li>The scenarios will illuminate these as well. </li></ul><ul><li>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. </li></ul>
    11. 11. How do we identify attributes? <ul><li>Attributes of the classes aren’t really supposed to be identified during the CRC session. </li></ul><ul><ul><li>They are an implementation detail. </li></ul></ul><ul><ul><li>Should go on the back of the card. </li></ul></ul><ul><li>But if you really, really want to, go ahead. </li></ul><ul><li>Find the adjectives . </li></ul><ul><ul><li>Adjectives imply attributes. </li></ul></ul><ul><li>The responsibilities of the class will help make these clear. </li></ul><ul><li>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. </li></ul>
    12. 12. How do we identify collaborations? <ul><li>Anytime a use case involves two or more classes, a collaboration exists. </li></ul><ul><li>Strong relationships exist when two or more classes are together in the same step of a scenario. </li></ul>
    13. 13. Conclusion <ul><li>A fun, effective way to work through OO Analysis. </li></ul><ul><li>Makes the art of identifying classes, responsibilities (methods), and collaborations simple. </li></ul>