CRC
• Before you can build an object-oriented system, you
have to define the classes (objects) that represent
the problem to be solved, how the classes relate and
interact, the inner workings of objects (attributes and
operations), and communication mechanisms
(messages) that allow them to work together
• Object-Oriented Analysis begins with a description of
use-cases. Class-Responsibility-Collaborator (CRC)
modeling transforms the information contained in
use-cases into a representation of classes and their
collaborations with other classes. The characteristics
of classes are then modeled using UML
CRC Cards
Responsibility
• What the class knows or does
• Student: have names, address, phone number,
enroll courses
An Example, the IIKH
• Imagine you are the chief software architect in a
major computing firm
• One day your boss rushes into your office with a
specification for the next PC-based product. It is
drawn on the back of a used dinner napkin, in
handwriting that appears to be your boss’s
• Briefly, the Intelligent Interactive Kitchen Helper will
replace the box of index cards of recipes in the
average kitchen
Your Job
• Your job is to develop the software that will
implement the IIKH
Abilities of the IIKH
• Here are some of the things a user can do with the
IIKH [identified as a result of a use-case analysis]:
–
–
–
–
–
–
–
Browse a database of recipes
Add a new recipe to the database
Edit or annotate an existing recipe
Plan a meal consisting of several courses
Scale a recipe for some number of users
Plan a longer period, say a week
Generate a grocery list that includes all the items in all the
menus for a period
Scenarios
• A scenario is an instance of a use case
– It expresses a specific occurrence of the use case
• A specific actor ...
• At a specific time ...
• With specific data
• Can be part of the Description field of a use case
CRC Cards
• Responsibilities
– Express responsibilities as short verb phrases
containing active rather than passive verbs
– Define what should be done, not how to do it
(declarative)
– Include only essential information, not a great deal of
detail
• Collaborators
– A collaborator for a class is another class with which the
first class collaborates to carry out its responsibilities
– The sender of a message usually is not one of the
collaborators of the receiver
CRC Cards
•
•
•
•
•
•
Identify an initial set of classes. Create one card for each
Identify an initial set of responsibilities and collaborators for
each card. This may lead to the identification of other
classes
Spread the cards out on a desk or attach them to a wall
For a group project, assign one or more cards to each
person in the group
Run through usage scenarios; as the flow of control passes
to a class, bring that card to a prominent spot
As the scenarios are played out, gaps in the design are
filled in. This is a form of iterative refinement
The Greeter
•
Let us return to the development of the IIKH. The first class
your team defines is the Greeter. When the application is
started, the Greeter puts an informative and friendly welcome
window (the greeting) on the screen
The Greeter
• Offer the user the choice of several different actions
–
–
–
–
–
Casually browse the database of recipes
Add a new recipe
Edit or annotate a recipe
Review a plan for several meals
Create a plan of meals
• Many of the details concerning exactly how this is to
be done can be ignored for the moment
A Component, The Greeter
• CRC card?
The Recipe Database
• Ignoring the planning of meals for the moment, your
team elects to next explore the recipe database
–
–
–
–
Must Maintain the Database of recipes
Must Allow the user to browse the database
Must permit the user to edit or annotate an existing recipe
Must permit the user to add a new recipe
Postponing Decisions
• Many decisions, such as the method of browsing,
can be ignored for the moment, as they are entirely
encapsulated within the recipe database, and do not
effect other components
– Scroll bars and windows?
– A virtual “book” with thumb-holes and flipping pages?
– Keywords and phrases?
• Only need to note that somehow the user can
manipulate the database to select a specific recipe
The Who/What Cycle
• As we walk through scenarios, we go through cycles
of identifying a what, followed by a who
– What action needs to be performed at this moment,
– Who is the class charged with performing the action
• Every what must have a who, otherwise it simply will
not happen. Sometimes the who might not be
obvious at first, i.e., who should be in charge of
editing a recipe?
Responsibilities of a Recipe
• We make the recipe itself into an active data
structure. It maintains information, but also performs
tasks
– Maintains the list of ingredients and transformation
algorithm
– Must know how to edit these data values
– Must know how to interactively display itself on the output
device
– Must know how to print itself
– We will add other actions later (ability to scale itself,
produce integrate ingredients into a grocery list, and so on)
The Planner
• Returning to the greeter, we start a different
scenario. This leads to the description of the Planner
– Permits the user to select a sequence of dates for planning
– Permits the user to edit an existing plan
– Associates with Date object
The Date
• The Date class holds a sequence of meals for an
individual date
– User can edit specific meals
– User can annotate information about dates (“Bob's
Birthday”, “Christmas Dinner”, and so on)
– Can print out grocery list for entire set of meals
The Meal
• The Meal class holds information about a single
meal
– Allows user to interact with the recipe database to select
individual recipes for meals
– User sets number of people to be present at meal, recipes
are automatically scaled
– Can produce grocery list for entire meal, by combining
grocery lists from individual scaled recipes