Introduction to CRC Cards

What is a CRC card ?

• CRC stands for Class, Responsibilities, and Collaborators
• A useful and popular technique for OO paradigm
• an index card annotated in a group setting to represent a class of objects, its behavior, and its interactions
• created in informal brainstorming sessions, wherein functions of the applications to be modeled are simulated and the outcome is recorded on the cards.

CRC Card Syntax

• NO universally accepted syntax for a CRC card
• The only essential elements are the class name, a set of responsibilities, and a set of collaborators
• The attributes and definitions of the classes can be written on the back of the cards.

An Example of CRC Card Syntax

• A collaborator is a class whose services are needed to fulfill one responsibility:
• Responsibility/Collaborator relationship is one-to-many
• Collaborators may be listed more than once on a card if they help to fulfill more than one responsibilities
• Collaborations are modeled as a one-way communication from the initiator class to the collaborator, assuming it can perform the requested service.

Advantages of CRC cards

• Simple:
• does not overwhelm the task of OO modeling.
• Group interactions:
• forster participants' creativeness that facilitates the brainstorming of good solutions
• Concrete role
• emphasizes the division of responsibilities across objects
• encourages an intuitive understanding of the model
• the size of the cards provides a guideline for class complexity
• The cards capture the essential aspects of the design: classes, responsibilities, and the patterns of interactions.
• inexpensive, portable, flexible, and readily available

How to play ? - CRC Card Session

• Cards are created in interactive sessions - groups of people responsible for modeling and solving the problem gather in a room and use the cards to guide the choice of classes, responsibilities, and collaborators
• Steps to conduct a CRC session:
• Choosing the group
• Preparing for a session
• Conducting the CRC sessions

Chossing Groups

• Optimal group size: 5 or 6 particpants
• # of disagreements proportional to the # of participants
• With large group, groups of cards that should logically belong to one person may be artificially split simply to ensure that everybody owns a card
• A group smaller than five may not have necessary range of problem domain and solution domain expertise
• A project may have observers who want to learn about objects or who want to understand the problem model or design for an application
• Democratic group, no dominator is allowed

Choosing Groups (Cont.)

• Group participants
• Domain experts:
• The domain expertise is what feeds the prosess of problem modeling by helping to create the scenarios and to choose the classes based on problem-related abstractions
• At least one is needed, and the number of domain experts may decrease as the sessions move from problem modeling into design
• object-oriented technology facilitator
• a person knowledgeable in object-oriented techniques who transfers his OO expertise to the group members
• a person who aids the CRC card analysis and design process by guiding the formulation of abstractions
• better to be an outsider who is generally a domain ignorant-free of biases, assumptions, and preconceived notions

Choosing Groups (Cont.)

• Developers:
  • responsible for turing the problem model into a working system
  • should participate from the beginning in order to the learn the domain as early as possible
  • Design influence early on can help build a problem model that maps more directly to design and implementation
• Testers:
  • Design sessions may include testers to help them understand how the system is supposed to operate
• Managers:
  • should be knowledgable enough about CRC cards and OO software development in general, otherwise, they can be harmful to session
  • see the process, and the progress, firsthand
  • be sensitized to technical, sociological, and staffing issues

Preparing for a Session

• A requirement document is the initial input to the process.
• The document should include a problem statement with associated goals for the application, a description of the operation of the system, and a set of constraints
• A project that cannot provide this information is not ready to begin modeling.
• Participants should have read and familiarized themselves with any of the documentation that will be used in the session
• Choosing a subset of the problem is essential for a session:
• A session should focus on one fairly small and manageable portion of the system at a time
• Subsystems can sometimes be inferred from the requirements, If not, a high-level functional partitioning of the system can be done as a starting point for the modeling

Conducting the Session

• The goal of a CRC sessionis to discover classes and convert them to CRC cards
• Eash participant is responsible for holding, moving, and annotating one or more cards as messages fly around the system in support of a particular need or activity

A Sample CRC Session

• The problem:
• An application supporting the operation of a technical library
• The operations include searching for and the lending of technical library materials, including books, videos, and technical journals. Users will enter their company ids in order to use the system, and they will enter material ID# when checking out and returning items.
• Each borrower can be lent up to five items. Each type of library item can be lent for a different period of time (book 4 weeks, journals 2 weeks, video 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 then $100

A Sample CRC Session (Cont.)

• Group members:
• two library domain experts: B and D
• two designers and implementors: C and J
• one object-oriented facilitator
• Initial problem partitioning:
• daily operations of the library such as checking out, returning, and searching for books, journals, and videos
• other system functions, such as generating overdue notices and sending bills to users' organizations
• user-interface subsystems
• database subsystems

A Sample CRC Session (Cont.)

• Finding classes in the problem:
  • Brainstorming: Facilitator, N, stands at the board soliciting the classes while D, B, J, and C offer suggestions
• The result:
  • Library, Librarian, User Borrower, Article, Material, Item, Due Date, Fine, Lendable, Book, Video and Journal.
  • J wonders if the User class is outside the scope of the system
  • C questions if Library and Librarian overlap too much to be a separate class
• Filtering the suggested classes:
  • The Library, Article, Material, Item, Due Date, and Fine classes are eliminated
  • A Date class is added
• The result:
  • Classes: Librarian, Lendable, Book, Video, Journal, Date, Borrower, and User
  • Due Date is an attribute of Lendable, Fine is an attribute of Borrower

A Sample CRC Session (Cont.)

• Assigning cards:
• based on who knows the most about an abstration or who will be responsible for a particular abstraction throughout the design and development of the system
• Each participant takes the cards, which they annotate with the class names they have been assigned
• They also write a short precise description of the class on the back of each card, then read these descriptions to the group for approval and mutual understanding

A Sample CRC Session (Cont.)

• The result:
• Fomer Person | Cards | Description of cards

A Sample CRC Session (Cont.)

• Identifying responsibilities and attributes
• Both can be derived from the requirements
• Often nouns that are not classes but characteristics of classes are best represented as attributes
• But, the best way to identify the responsibilities and attributes is to discover scenarios, execute them and see what behavior is necessary to get the job done.

A Sample CRC Session (Cont.)

• Scenario discovery
• The heart of the CRC card session is the walk-throughs of the application driven by scenarios
• Scenarios are detailed examples of the functions (not refer to a procedural block) of the system
• For each function, a set of scenarios exists that explores what would happen given different parameters. For example, the functions of the Library application are checking out items returning an item, and searching for an item
• Scenarios to be explored are the "what happens when"'s that illustrate the expected use of the system. For example, "What happens when Stephanie Ross returns a video, Introduction to C++, to the Librarian?".
• The least complicated scenarios should be modeled first. More difficult and complex situations may have components that are simpler scenarios.

A Sample CRC Session (Cont.)

• Scenario execution
• The simulation of the scenarios should be dynamic and anthropomorphic (using human to do simulation)
• The set of cards on the table is static, while executing scenarios, cards are raised to simulate the dynamic behavior of the system where messages are sent to actual objects performing their tasks. Thus, the card is a class when on the table and an object when in the air.
• As each separate action supporting the scenario is identified, it is assigned to a particular card as a responsibility
• An example (a checking-out scenario): "What happens when Barbara Stewart, who has no accrued fines and one outstanding book, not overdue, checks out a book entitiled Effective C++ Startegies?"

A Sample CRC Session (Cont.)

• Cards after the execution of the checking-out scenario

A Sample CRC Session (Cont.)

• Identifying Superclass from similar scenarios
• Another "check-out" scenario: "What happens when Bronwyn Glor, who has one outstanding book, not overdue, checks out the video A Basic, Visual Introduction to Visual Basic?"
• Similarly can be found in Book, Video, and Journal. The superclass of the three classes is Lendable.

A Sample CRC Session (Cont.)

• Superclass discovery
• Lendable
  • - Video
  • - Book
  • - Journal

A Sample CRC Session (Cont.)

• More scenarios:
  • return scenarios
  • exceptional scenarios
• Discovering new classes
• Often, as scenarios are executed, a group realizes that none of the classes on the table is appropriate to house a particular responsibility. This spurs the creation of a new class with the appropriate behavior.
• Example: A Collection class needs to be added to the Library application system to handle the scenario like "What happens when Ned Brooks comes to the Library in search of a book entitled The Mythical Mammoth?"

A Sample CRC Session (Cont.)

• Grouping cards:
• The grouping physically mimic the relationships between classes
• Hierarchies of classes, for example, Lendable and its subclasses, are often stacked on the table
• Classes that collaborate heavily should also be close together on the table to accentuate the amount of cooperation between them

A Sample CRC Session (Cont.)

• Scenario List
• It is an important task in the CRC process to record the scenarios as they are suggested and executed
  The list can be used to illustrate to others the way in which the model can be exercised to fulfill the workings of the system.
• It is an important part of the documentation of a CRC card design
• Collaboration Drawings:
• Drawing collaboration lines between the groups of cards

CRC Cards for Analysis

• Stengths of CRC cards for analysis
• Common project vocabulary
• Spreading domain knowledge
• Making the paradiagm shift
• Live prototyping
• Identifying holes in requirements
• CRC elements at the analysis stage
• Classes
• Scenarios and responsibilities

Reuse and CRC Cards in Problem Modeling

• Reuse of domain-level classes or architectural frameworks
• When entering a CRC card session, it is important to know what domain classes and frameworks exist to help model the problem
• CRC card sessions can also help create new domain classes or generalize existing ones to make them more reusable across applications
• Card as Input to a Formal Methodology (Semi-formal)
• To Booch method
• To Rumbaugh method
• ...

CRC Cards for Design

• CRC elements at the design stage
• Classes
• Scenarios and responsibilities
• Attributes
• Documenting a CRC card design
• Class model
• Class descriptions
• Scenario Descriptions