CRC Cards - Tutorial
Jun & Azene
OBJECTIVES
After completing this tutorial, you shall be able to
– Know what CRC card is and its history
– Know a CRC card session and run
– Use CRC for analysis and design of a real objectoriented application
– Know CASE tools for CRC cards
– Know its strengths and limitations
OUTLINE
•Introduction:OO Concepts and Vocabulary
•CRC: Overview
•CRC Cards for Analysis
•CRC Cards for Design
•Documenting a CRC Card Design
•CASE Tools for CRC Card Design
•Exercise: ATM Simulation using CRC
•Discussions on the results of the exercise
INTRODUCTION
OO CONCEPTS AND
VOCABULARY
INTRODUCTION
“Object-oriented programming offers a new and powerful model for
writing computer software. This approach speeds the development of
new programs, and, if properly used, improves the maintenance,
reusability, and modifiability of software. O-O programming requires a
major shift in thinking by programmers, however. The C++ language
offers an easier transition via C, but it still requires an O-O design
approach in order to make proper use of this technology. … .”
Source:http://catalog.com/softinfo/objects.html
OO Concepts and Vocabulary
OO v/s Non-OO
Procedures
• Non-Object-Oriented (Traditional)
– Data and Procedures are kept Separate
– Procedures work on Data to produce results
• Object-oriented
– Focus on Responsibilities - to be satisfied
by Objects
– Responsibilities translate into Data and
Functions within an Object
– Objects have behavior
Source: Dr. Seaman’s Lecture Note
Data
Data
Procedures
OO Concepts and Vocabulary(Cont.)
Phases of OO Systems Development Cycle
Implementation
System Design
Analysis
-application
-what
-system architecture
-database access -programming
-database access
-data structure
-algorithms
-controls
Object Design
Source: Jeffrey(1999). Advanced System Analysis and Design
OO Concepts and Vocabulary
(Cont.)
•
•
•
•
•
•
•
•
Objects:State,Behavior,Identity
Object-Oriented Model
Encapsulation
Instantiation:Classes and Objects
Inheritance:Classes,Super-classes,and Subclass
Abstract Classes
Polymorphism
Framework and Patterns
THE CRC CARD
OVERVIEW
WHAT’S CRC Card?
CRC stands for Class,Responsibility,and Collaboration.
• Class
– A set of objects that share common structure and common behavior
Super-class : a class from which another class inherits
Subclass: a class that inherits from one or more classes
• Responsibility
– Some behavior for which an object is held accountable.
• Collaboration
– process whereby several objects cooperate to provide some higher-level
behavior.
WHAT’S CRC CARD? (Cont.)
• An index card that is annotated in a group setting
to represent a class of objects,its behavior,and its
interactions.
• An informal approach to OO modeling
• Created through scenarios,based on the system
requirements,that model the behavior of the
system.
WHAT’S CRC MODELING
• CRC Modeling is used:
– to develop an OO system more easily
– to teach people about objects and their relationships
without teaching them an entire programming language (or
even mention programming)
• CRC is implemented using the requirements given to
a team
• Each class is written down on a 3x5 (4x6) inch index
card
Sample CRC Card (Front & Back)
REQUIREMENTS
• Cards should be physical cards, not virtual cards.
• CASE tools for support of CRC cards are
useful,but cannot replace the interaction that
physical cards facilitate.
• 3x5 or 4x6 inch are the perfect size. But you can
really use anything you want.
….Napkins???Denny’s???
• Refreshment (Optional)
HISTORY
• Introduced at OOPSLA in 1989 by Kent Beck and
Ward Cunningham as an approach for teaching
object-oriented design.
• In 1995,CRC cards are used extensively in
teaching and exploring early design ideas.
• CRC cards have become increasingly popular in
recent years. As formal methods proliferate, CRC
cards have become, for some projects,the simple
low-risk alternative for doing object-oriented
development.
THE CRC CARD SESSION
•
•
The session includes a physical simulation of
the system and execution of scenarios.
Principles of successful session
–
–
–
All ideas are potential good ideas
Flexibility
Group Dynamic
BEFORE THE SESSION
• Forming the Group
– The ideal size for the CRC card team:
• 5 or 6 people
– The team should be composed of
•
•
•
•
One or two domain experts
two analysts
an experienced OO designer
one group’s leader/facilitator
The CRC Card Team
Source:The CRC Card Book by Bellin et.al (1997)
DURING THE SESSION
• All the group members are responsible for
holding,moving and annotating one or more cards
as message fly around the system.
• Group members create,supplement,stack,and wave
cards during the walk-through of scenarios.
• A session scriber writes the scenarios.
PROCESS
1.Brainstorming (Productive thinking)
–
One useful tool is to find all of the nouns and verbs in the problem
statement.
2. Classes Identification
–
The list of classes will grow and then shrink as the group
filters out the good ones.
3. Scenario execution(Role play)
–
The heart of the CRC card session
STRENGTHS
• The cards and the exercise are non-threatening &
informal
• Provide a good environment for working and
learning.
• Inexpensive,portable,flexible,and readily available
• Allow the participants to experience first hand
how the system will work
• Useful tool for teaching people the object-oriented
paradigm
LIMITATIONS
• Provide only limited help in the aspects of design.
• Do not have enough notational power to
document all the necessary components of a
system.
• Do not specify implementation specifics.
• Can not provide view of the states through which
objects transition during their life cycle.
CRC GOOD PRACTICE
•
•
•
•
•
Start with the simplest scenarios.
Take the time to select meaningful class names.
Take the time to write a description of the class.
If in doubt,act it out!
Layout the cards on the table to get an intuitive
feel for system structure.
• Be prepared to be flexible.
CRC CARDS FOR ANALYSIS
Overview
Analysis techniques to OO development focus
on discovering:
– problem and application domains’ objects and
classes
– relationships that exist between these objects &
classes
– way that objects undergo state changes and/or
interact with each other over time
CRC for Analysis
• CRC Elements in Analysis:
– classes, scenarios, responsibilities & collaborators
– Use the CRC Card sessions to elicit analysis
classes, responsibilities and collaborations
• Analysis classes:
 are classes those describe what the system does
 reflect concepts and entities that are part of the domain
of being modeled
 objects of these classes collaborate to describe what
the application does
• To create an OO model of an application
Case Example:
A small technical library system for an R&D
organization
•
•
•
•
•
Requirement Statement
The CRC Card Sessions
Participants (Who? Why?)
Brainstorming (Scope)
Creating Classes (the first step)
– Brainstorming
– Suggesting Classes (your suggestions)
– Filtering
Case example: Finding Classes
• Suggested Classes
– Library, Librarian, User, Borrower, Article,
Material, Item, Due Date, Fine, Lendable,
Book, Video, and Journal
• Classes after filtering
– Librarian, Lendable, Book, Video, Journal,
Date, Borrower and User
• Assigning Cards
– A CRC Card per Class, put name & description
of the class
Scenarios execution
• Scenarios executions/Role Plays (For what?)
– Filter & test identified classes
– Identify additional classes
– Identify Responsibilities and collaborators
• can be derived from the requirements/use cases
• responsibilities that are "obvious" from the name of
the class (Cautious, avoid extraneous responsibilities)
– Filtering and testing R & C
– Attributes
• (Only important ones are noted)
Finding Responsibilities
• Are things that the class has knowledge about
itself, or things that the class can do with the
knowledge it has
• Tips/Indicators
– Verb extractions in the problem or use case
– Ask what the class knows? What/how the class does ?
– Ask what information must be stored about the class
to make it unique?
Finding Collaborators
• A class ask another class when
– needs information that it does not have or
– needs to modify information that it does not have
• Client (Requester for services) - Server
(Services Provider) relationship
• Tips/Indicators
– Ask what the class does not knows and need to
know? And who can provide that?
Case example: Scenarios Execution(cont.)
• Identify Scenarios (By domain experts)
• Main Categories: check-out, return and
search
• CHECK-OUT SCENARIO
– Who should have the overall responsibilities for
the task/check out? Librarian.
– What does the task/checking out a book entails?
– Refer to the Script to follow the process
(handed to students)
Case example: Scenarios Execution(cont.)
• Major Questions
– Shouldn't there be collaborations in the
opposite direction?
• Collaborations in CRC cards are one-way
relationships from the client to the server (OO)
– Who should do the checking out of the Book?
Librarian or Book itself? (Controversial)
– Who should tell Borrower to update its
knowledge about outstanding Book? Librarian
or Book?
Case example: Scenarios Execution(cont.)
• Do we need a collaboration between Book
and Borrower for the know set of books
responsibility?
– Collaborations are not usually needed for
responsibilities that simply hold information.
Instead, Collaboration is needed only for
situations where an object actually sends a
message to a Collaborator.
– Borrower does not need Book's help to put a
Book in a set.
CRC Cards after the first scenario run
Case example: Scenarios Execution(cont.)
• Remarks:
 Domain experts have a lot contribution
 The first scenario takes the longest to walk-through
and set the framework
– Related scenarios
• Superclass discovery
• Return scenarios
• Exceptional scenarios
Case example: Scenarios Execution(cont.)
• Search Scenario
– "What happens when Ned comes to Library in
search of a book entitled The Mythical Mammoth?"
– Discovery of new class: Collection class (Why?)
• Book can’t look for itself, identity of the book is not know
– Collection looks over a set Books to find the correct
• Attributes for searching (can be done at Design stage)
• When to end scenario execution?
– Get a stable model (does not cause new C or R to be added)
Grouping Cards
 CRC cards on the table provides a visual
representation of the emerging model
 Classes with hierarchical (is-a relationship)
 Class who collaborate heavily placed closer
 Class included by other class (has-a
relationship); e.g. Date in Lendable
 Card clustering based on heavy usage or
collaborations can provide visual clues to
subsystems
Deliverables
• Documenting a CRC Card Analysis
– Complete list of Library Application CRC
Cards
– List of scenarios recorded as suggested and
executed
– Collaboration Diagram
– Application Problem Model
Strength & Limitation for Analysis
• Common Project Vocabulary
• Spreading Domain Knowledge
• Making the Paradigm Shift (Role play)
• “Every participant is an object, everything happens does
so because an object makes it happen” (Wilkinson 1995)
• Live Prototyping
– to show what the system suppose to do to customers,
new member, testers, developers, etc.
• Identify Holes in the Requirements
• Limitation
CRC CARDS for DESGIN
• Goal of CRC card design process
 Expansion and refinement of the Analysis CRC
 At level where implementation will be fairly clear
• Analysis Classes - describe what the system
does. Design Classes - describe how the
system works.
•
1..N Analysis Classes
– CRC Card design sessions: Additional classes and
mechanisms are built upon the existing analysis classes
•
0..N Design Classes
Design
• Design classes:
 are classes those describe how the system does
 reflect concepts used by designers and programmers
to describe their implementation techniques
 include classes that contain the data structures and
operations used to implement the analysis as well as
classes representing the user interfaces, DBMS,
error handlers, etc.
 objects of these classes collaborate to describe how
the application goals will be accomplished
Design
 Design Constraints
 Target Environment and Language
• Choice of Supporting Software Components: GUI
and DBM systems; general and special purpose
libraries and frameworks
• Class Libraries
• Performance Requirements: response-time/ speed,
expected availability, load in terms of number of
users
• Errors/Exceptional Handling
• Other: Security, Memory, etc. constraints
Applying CRC cards for Design
• Elements: CRC, Attributes, scenarios, subresponsibilities, Lifetime of objects
• Classes
 Additions that represent mechanisms that support
implementation of the problem e.g. Search class
 Classes contain the data structures and operations
used to implement the analysis classes e.g. Array,
List
 Interface classes for UI and DBM subsystems
 Classes to handle error conditions
Applying CRC cards for Design
• Scenarios, Responsibilities & Collaborators
 take the implementers’ point of view in fulfilling these
scenarios, i.e., detailing all system functions
(responsibilities), including those that provide support
functions (collaborators)
 Sub-responsibilities to be added
 Collaborating sub-responsibilities to be added
 Message Data Passed (can be differed until the low-level design)
 The Process:
 Problem-modeling scenarios are repeated along with
additional new scenarios as needed
 High-level responsibilities & collaborators are used, and
detailed and expanded
Applying CRC cards for Design
 The distinction between objects and classes becomes
more important, and the following questions, are
answered will be an important part of its design.
 Who creates this object?
 What happens when it is created and adopted?
 What is the lifetime of the object vs. the life time of the
information (persistence) held by an object?
• Attributes
 Discovery of attributes that are necessary to support the
task during examination of each responsibility
 What attributes of objects need to be saved persistently
 Leads to a database design (database model)
Case: Library Application Design
• Group: Who and why?
– The two designers (Cecilia and Jim), OO expert (Nancy) as a
facilitator, Betty (a domain expert/user)
• Input: CRC cards, Scenarios, diagrams, etc.
from Analysis stage; Design Constraints
• The Session/Process
– Brainstorming
• Add sub-responsibilities while revising the analysis classes
• Add data/object that is passed with the message being sent
(can be differed at the end of the design stage as it takes the
design to low level)
» Figure 5.3. pp. 116
Case: Library Application Design
• Brainstorming any classes that comes to
mind based on design constraints such as
– User Interface, Database access, Mechanisms for
implementation of analysis classes, error handlings
– User Interact class & DB interface Classes
• Scenarios identification and executions
•
•
•
•
Object creation scenarios
Check-out Scenario
Return Scenario
Search Scenario
• Output: Design classes
Case: Library Application Design
• Classes that serves as interfaces to other
subsystems (UI and DBMS)
• Principles:
 make independent of specific hardware and software
products
 use specific class names instead of generic names such as
GUI and DBMS
• User interface: to get input from and display
to user using GUI software classes
 UI manager, User Interacter classes are suggested.
Case: Library Application Design
• Database: To obtain and store Borrower
objects and objects of the Lendable classes
using DBMS software
• Scenario Executions (Scripts given)
– Creation Scenarios (System start-up)
– Check-out scenario
– Others
Case: Library Application Design
• some important issues during Scenarios
execution
• How to verify the ID? Who? Librarian? A new class?
• How the Lendables set are stored and manipulated?
Data Structure issues? List is chosen
• Scenarios, Scenarios, Scenarios
– Work on normal and exceptional (Error handling
class)
• When to start Prototyping?
Deliverables
• Documenting a CRC Card Design
– List of design classes (pp. 130-2)
– Class models: Hierarchies and collaboration
graphs (pp. 142-3)
– Scenario Descriptions (pp. 145-7)
Strength & Limitation for Design
•
•
•
•
•
•
Common project vocabulary
Spread of domain knowledge
Spreading OO design expertise
Design Reviews
Frame for implementation
Informal notation
– “Designing is not the act of drawing a diagram”
(Booch)
• Limitations
CASE tools for CRC Card
•
•
•
•
An automated tool to support CRC cards
Quick CRC from Excel Software
From SpiralSoft
Rational & others Modeling Methods and
CASE Tools.
• Features
www.excelsoftware.com
http://www.spiralsoft.com/Html/DownloadCRC.html
http://mlwww.diee.unica.it/TABOO/OO-CASE-tools.html
Class Exercise
Case: Simulation of AMT
References
Wilkinson, N. C. (1995). Using CRC cards: An informal approach to object-oriented development.
SIGS Book, USA
Bellin, D. and Simone, S. S. 1997. The CRC Card Book. Addison Wesley Longman, Inc.: USA.
Beck, Kent, and Ward Cunningham. " A Laboratory for Teaching Object-Oriented Thinking."
OOPSLA-89 Proceedings, SIGPLAN Notices 24 (10): 1-6 (October 1989). URL: http://www.
Jeffrey, H. and et al. (1999). Modern systems analysis and design. Reading, Mass: Addison-Wesely.
Bjork, R. C. 2000. ATM Simulation Links - by Topic.
http://www.cs.gordonc.edu/local/courses/cs211/ATMExample/index.htm
Techniques for Object Oriented Analysis and Design. http://www.aw.com/cseng/titles/0-201-895420/techniques/index.htm
Object-Oriented Design Using CRC Cards. http://www.d.umn.edu/~gshute/ood/
Malan, R., et al. (1995). Lessons from the Experiences of Leading-Edge Object Technology Projects
in Hewlett-Packard. OOPSLA'95 Conference Proceedings, Austin, Texas.
Hutt, A.(1994). Object Analysis and Design: Description of Methods. JohnWilley & Sons, Inc., New
York.
Fowler, Martin. (1997). A survey of object oriented analysis and design methods.
http://ourworld.compuserve.com/homepages/Martin_Fowler/
Reference (Cont.)
A tool for designing Java programs with UML . Proceedings of the 4th annual SIGCSE/SIGCUE
on Innovation and technology in computer science education, June 27 - 30, 1999, Krakow
Poland www.acm.org/pubs/articles/proceedings/cse/305786/p180-armentrout/p180-armentrout.pdf
Object-oriented practice in 1998 (panel): does it help or hinder collaboration? Pages 45-47.
http://www.acm.org/pubs/articles/proceedings/oops/286936/p45-artim/
CRC CARD CONSTRUCTOR. http://www.engin.umd.umich.edu/CIS/tinytools/cis375/f00/crc/crc.htm
Techniques for Object Oriented Analysis and Design. http://www.aw.com/cseng/titles/0-201-895420/techniques/index.htm
Cockburn, A. (March 1999) Using CRC Cards [Online].
http://members.aol.com/humansandt/techniques/crc.htm [03/29/2001].
SpiralSoft Home Page. http://www.spiralsoft.com/Html/DownloadCRC.html
Object-Oriented Design Using CRC Cards. http://www.d.umn.edu/~gshute/ood/
Object-Oriented Analysis Phase www.cdt.luth.se/pvt/courses/smd114/2000/lectures/Schach/ch11/index.htm
Modeling Methods and CASE Tools. http://mlwww.diee.unica.it/TABOO/OO-CASE-tools.html