Proc. 2nd CeTUSS Worskop on Computer Science Education, Linkping, Sweden, Apr 2007.

CRC-Cards and Roleplay DiagramsInformal Tools to Teach OO Thinking

jubo@[Link]

Introduction

CRC-cards (

Class, Responsibility and Collaborator) are a lightweight approach to collaboraclass.

tive object-oriented modelling that has been developed as a tool for teaching object-oriented thinking to programmers [1]. They have been used widely in various teaching and training contexts [2, 6, 7, 10]. A CRC-card (see gure 1) corresponds to a A

responsibility

is something the objects of a class know or do as a service for other

objects. A book object in a library application, for example, might, among other things, be responsible for checking itself out and knowing its title and due date (see A responsibilities of the objects of a class are written along the left side of the card.

collaborator is an object of another class helping

to full a specic responsibility.

A book object, for example, can only know whether it is overdue, if it also knows the current date. In gure 1 this information is provided by a collaborator object of class Date. The class names of collaborators are written along the right side of the card. The back of the card can be used for a brief description of the class' purpose, comments and miscellaneous details.

Class:

Responsibilities

Book

Class:
Collaborators

knows whether on loan knows due date knows its title knows its author(s) knows its registration code knows if late check out
Class:

Responsibilities

Librarian

Date

check in book check out book search for book knows all books search for borrower knows all borrowers

Collaborators

Book Book, Borrower Book Borrower

Responsibilities

Borrower

Class:
Collaborators

knows its name keeps track of borrowed items keeps track of overdue fines

Responsibilities

Date

knows current date can compare two dates can compute new dates

Collaborators

Fig. 1. A set of CRC-cards for modelling a simple library application.

Using CRC-Cards

The CRC-card approach can be roughly divided into two stages; (1) development of an initial CRC-card model and (2) scenario denition and roleplaying. In the roleplaying, participants act-out predened scenarios, much like actors following a script when playing the characters in play. In object-oriented development, the characters of the play are the objects in a software system and the scenarios are hypothetical but concrete situations of system usage. The roleplaying helps students learn to think in objects in the following way [1]:

1. Students can only control their own assigned role(s) (i.e. CRC-card(s)); this helps them to give up global control [8]. 2. Students can only act according to the predened responsibilities of their role(s); this helps them to focus on design, i.e. distribution of responsibilities [10]. 3. Students collaboratively enact how their system should work; this immerses them in the object-ness of the material [9].

Borrower

Book Librarian
Som eC

Fig. 2. Roleplaying is a collaborative activity.

We have successfully used CRC-cards in our introductory programming courses for many years. It forces participants to reason about models and explain design decisions to their peers. This makes the approach particularly useful for collaborative active learning. However, we have also noticed a few problems, in particular with respect to the roleplaying (see [5] for more details): 1. CRC-cards blur the dierence between objects and classes. CRC-cards serve two roles; they are used as surrogates for classes in model development and as surrogates for objects in the roleplaying. This makes it even more dicult for the students to understand the important dierences between class and object. 2. It is unclear what makes a good scenario. Ambiguous or unclear scenarios leave too many degrees of freedom and make exploration very dicult. 3. Students get easily lost during the roleplaying. Roleplaying is explorative, i.e. many dierent paths are tested and decisions about the kind and order of messages send are revised and rened continuously. This makes it very dicult to backtrack to a consistent state in a scenario, in particular, when the underlying design is changed (which might make earlier decision invalid). 4. There are no guidelines for the mechanics of the roleplaying activities. 5. There are no guidelines for the documentation of scenarios and roleplays.

Roleplay Diagrams

To support the roleplaying, we needed a to help the students keeping track of their decisions. A simple and intuitive notation should make it possible to successively built up the documentation of the roleplay on the y as the scenario unfolds. This documentation must furthermore be very easy to change. Otherwise, the dynamics of the roleplaying would be disturbed. The documentation should support the roleplaying, not the other way around. These requirements ruled out raw text or existing UML diagrams [4]. We tried raw text and sequence diagrams in the beginning, but they are too dicult to change and reorganize. Another disadvantage of sequence diagrams is their lack of structural information. Structural information is, however, very important for capturing all relevant status information at scenario start to make clear which objects are allowed to communicate. Furthermore, it is

know lass know s XXX S Y om YY can s eClaOth do kn AA ss er ow A know s XXX can s YYY do A Oth AA er

Som

eC

lass SomeC s XXX

Date

kno la kno ws XX ss can ws YY X Y do AA Oth A er

Other know YYY s know AAA can do

ss er eCla X laO ssth Somows XX Y YeC X Som XX

kn s Y nA As YYY ow A s know do k A know do AA can can

impossible to describe attribute values in sequence diagrams (as well as in collaboration or communication diagrams). The only UML diagram covering structural information and attributes is the object diagram. They, however, do not capture message passing, the most important aspect of scenario documentation. We therefore developed roleplay diagrams (RPDs) by combining elements from UML's object and collaboration diagrams

1 . Objects in RPDs are represented by object cards.

An object card is an instance of a CRC-card showing an object's name, its class and the properties relevant for the current scenario. In gure 3, for example, we have an object which is an instance of our CRC-card (class)

Book

book1,

from gure 1. For each new object, we

create a new object card and put it on the white-board or a large sheet of paper. This helps to make clear the distinction between objects and their corresponding classes.

book2: Book theGUI

1: check out 1984 to John Doe

: Librarian

borrower1: Borrower

Fig. 3. Snapshot of an evolving RPD for checking out book 1984 to borrower John Doe.

Object to object communication is only possible if the participating objects know each other in the particular scenario. Objects that know each other are connected by a line. Please note, that two objects can only be connected when they are collaborators (see CRCcards). A service requested (message sent) by an object must correspond to a responsibility listed on the CRC-card corresponding to the serving object. In our example, correspond to

check out
message

Book's

responsibilities

knows whether on loan

and

on loan? and check out,

respectively (see gure 1). If there are no corresponding responsibilities, as for example for

in our example, the design (i.e. CRC-card model) must be revised. Messages are

documented on the connecting lines between the communicating objects. Small arrow denote the direction of messages. A simple numbering scheme is used to keep track of the ordering of messages. Messages can be annotated with information that is returned. When the knowledge of an object changes, the corresponding object card is updated accordingly. After checking out changes. Please note that the connection between

book1

its property

on loan

is changed to

yes.

At the end

of a scenario roleplay, the RPD documents exactly what happened, including relevant state

book1

and

borrower1

(dotted line in gure 3)

is not present at the start of the scenario. It is established as a result of sending message

3.

Experience

Our experience with CRC-cards and RPDs is very positive [5, 6]. The approach supports object thinking and helps students understand the dynamics of object-oriented programs.

Actually, RPDs are closer to Booch's original object diagrams [3] than any of the current UML diagrams

The RPDs are useful for dening the start situation of a scenario and then recording the roleplaying as the scenario evolves. This makes RPDs an excellent tool for scenario tracking, testing, and documentation. Design decisions can be tested without writing a line of code. Some of our students actually use the CRC/RPD approach as their design method of choice in other courses. In table 1, we summarize results from the course evaluations of all oerings of our introductory programming course for the period spring 2001spring 2005. In these evaluations students can report problems in free form, which we divided into We have grouped the 12 oerings into four groups; courses covering neither CRC-cards or RPDs, but including GUIs (column CRC-cards (column (column

CRC/RPD,

CRC,

no CRC, no RPD, 2 oerings); courses covering pure

6 oerings); and courses using the proposed CRC/RPD approach

3 oerings). One oering, covering GUIs and CRC-cards was excluded

from the summary, since it did not t a category. Please refer to [5, 6] for more details.

Table 1. Percentage of students reporting problems in course evaluations, by problem category.

no CRC, no RPD CRC CRC/RPD avg. CRC & CRC/RPD Students answering, total Students reporting problems Problem categories: - OO thinking - OO concepts - Design/CRC/RPD - Coding assignments - Everything - I/O - GUI - Other 3.86 10.38 1.59 8.56 6.44 4.17 12.05 8.56 3.38 4.17 4.02 14.68 9.74 10.29 0 15.63 3.18 2.77 7.95 1.82 10.84 3.81 0 8.50 3.31 3.71 5.33 10.39 10.11 8.13 0 13.25 126 55.61 156 61.91 111 38.87 267 54.23

Although the data in table 1 is dicult to interpret, it seems to support our claim that CRC/RPD has a positive eect on the understanding of object-oriented concepts. These results are particularly remarkable, since student cohorts in the beginning of the period reported here have been generally stronger than those towards the end of the period. We specically want to stress that the CRC/RPD approach does not require any prerequisite knowledge in programming. In fact, students with good programming knowledge often have diculties focusing on responsibilities, which are on the analysis or design level. They often start discussions about irrelevant low level details. Since their arguments can be very convincing for inexperienced programmers, we strongly recommend to carefully monitor the discussions and interrupt such discussions. Building inhomogeneous teams helps to avoid such problems. Our experience shows that roleplaying is dicult. The introduction of RPDs helped to overcome most problems. To give students a good start, we have developed a tutorial with guidelines and examples. Furthermore, we present a live-demo in front of the class. In general, students are positive toward the CRC/RPD approach. When asked Have the CRC exercises been rewarding?, on average about 2.5 times as many students are clearly positive than clearly negative. To make using the CRC/RPD approach successful, we strongly recommend the following:

Carefully distinguish between classes and objects. Make scenarios as specic as possible.

Avoid using CRC-cards as

substitutes for objects during the role-play.

Restrict the degrees of freedom to a few

things that should be explored. One can easy get lost in long or open-ended scenarios. A good scenario should have a clear goal, well-dened preconditions and an expected outcome.

Start with the simplest possible meaningful scenario. It is important to make the
rst role-play a successful activity to motivate students to use the technique.

Initialize the role-play properly.

Carefully set up all objects that already exist at

scenario start (for collections choose a few representative elements). Initialize objects with all relevant information as stated in the preconditions for the scenario. Introduce a single GUI object that handles all communication with users and external systems and connect it to at least one object in the model.

Be careful with object names. Novices easily confuse objects, properties, and refer-

ences, when they are named similarly.

References
1. Kent Beck and Ward Cunningham.

Proceedings OOPSLA'89, pages 16, 1989.

A laboratory for teaching object-oriented thinking.

In

2. Robert Biddle, James Noble, and Ewan Tempero. Reections on CRC cards and OO design. 3. Grady Booch.

Proceedings Tools Pacic 2002, pages 201205, 2002. Object-Oriented Analysis and Design with Applications, 2nd edition.
Addison-Wesley, Reading, MA, 1999.

Addison-

Wesley, Reading, MA, 1994. 4. Grady Booch, James Rumbaugh, and Ivar Jacobson.

Guide.

The Unied Modeling Language User OOPSLA'05 Ad-

5. Jrgen Brstler. Improving CRC-card role-play with role-play diagrams. In

dendum to the Proceedings (Educators' Syposium), pages 356364, 2005.

6. Jrgen Brstler, Thomas Johansson, and Marie Nordstrm. Introducing oo concepts with CRC 7. Jim Coplien. Experience with CRC cards in AT&T.

Proceedings FIE'02, pages T2G1T2G6, 2002. C++ Report, 3(8):1,46, 1991.

8. Mark Guzdial. Centralized mindset: A student problem with object-oriented programmings. In 9. David West. 10.

Proceedings SIGCSE'95, pages 182185, 1995. Object Thinking. Microsoft Press, Redmond, WA, 2004. Nancy Wilkinson. Using CRC Cards, An Informal Approach to Object-Oriented Development.
SIGS, New York, NY, 1995.