CRC Cards C lass  R esponsibility  C ollaborator Copyright © 1999 Patrick McDermott UC Berkeley Extension Although not strictly part of the UML, CRC (Class-Responsibility- Collaborator) Cards are often useful for learning requirements from users.

Class A Thing the Business needs to know about. At this stage, a business person should be able to understand every one of them. “Class” is best defined by examples…

Examples of Classes Tangible Intangible People Places Things Events Roles Organizations Other Systems Collections of Other Objects Conceptual: Cost Center, Account Interface: Screen Infrastructure: Date, Money, Address Persistence: Database Control

There Must be a Class if… … There’s a file … There’s a form … There’s a number … There are multiple copies … It’s Important NOTE— –Sections and boxes on Forms –The name might not be obvious They’re Everywhere!

Classes have Responsibilities Personification Helps –What if a person, not a computer, does it? –Obligation or Contract Know Things –Invoice: Know who the Customer is Do Things –Invoice: Compute Total Get Organized –Abstraction

A Responsibility might use a Collaborator Some Relationship between two classes Another class that assists in fulfilling the Responsibility –Has information (Knows something) –Helps accomplish the Task –No need to List Both Directions (Reverse is implied) A verb should connect the two A Customer Pays an Invoice A Student Registers for a Class Personification (or messaging) can help –The Pathetic Fallacy is Preferred –Act Like the class is a Person –How was it done B.C.? [Before Computers]

A CRC Card A ResponsibilityCollaborator Another ResponsibilityCollaborator A Great ResponsibilityCollaborator NAME

Attributes Attributes are facts about classes Do not attempt to list all possible attributes List only attributes that are –Defining –Likely to be forgotten –Politically Important Do not make get/sets for all attributes

A CRC Card Session 1.Prepare the Group Ice Breaker? Choose a scribe 2.Brainstorm Class List 3.ACE it: Add, Combine, Eliminate 4.Make Cards 5.Write Descriptions 6.Brainstorm Responsibilities & Collaborators 7.Review 8.Sketch UML Class Diagram with Cards

Brainstorming Rules 0. Have Fun!!! 1. No Criticism or Debate 2. No Self-Censorship 3. Piggyback Quantity not Quality

Steps 1. Brainstorm 2. Reward 3. Reality Check 4. Fuse & Fission 5. Categorize, Cluster & Combine 6. Select Consensus Multi-Vote

Purchase Order A Purchase Order (PO) is prepared by a customer and sent to us to order goods or services. The term "Purchase Order" has a special legal meaning under the Uniform Commercial Code (UCC) and implies a huge volume of terms and conditions that are set out in the UCC.

Packing Slip A PO is technically a legal offer to pay us a certain amount for the goods ordered. We can turn the PO into a contract by accepting the offer. The simplest way to accept an offer is to perform on it, in this case by shipping the goods. We prepare a Packing Slip as a record of the shipment.

Invoice An Invoice is a demand for payment. The invoice is sometimes legally necessary but also shows the customer the calculation of the total.

Receipt A Receipt is acknowledgement of payment. Receipts are usually only prepared when the payment is in cash; in other cases the customer’s canceled check serves as the receipt.