CRC card example

Spring 1998

Nic McPhee
University of Minnesota, Morris

Not surprisingly, there seems to be some confusion about exactly what these CRC cards are about. In this document I'll try to provide some tips and guidelines along with a specific examples.

Some guidelines

First, let's assume here that we're starting with a scenario and trying to lay out the major players. A scenario should be a complete sentence, and as such it should have nouns and verbs. The nouns should be the entities or classes in the system, and they will almost always turn into specific cards, with different nouns turning into different cards. The verbs in the scenario typically turn into the responsibilities of some card, i.e., some action an entity is capable of performing. Note, however, that complex activities often turn into a number of different actions performed by several different entities. The collaborators section of a card is the list of entities (other cards) that this particular card is going to have to know about, i.e., directly access. When working through a scenario you only need to worry about the pieces necessary for that scenario. Don't make the mistake of trying to (re)invent the entire system every time you work through a new scenario.

A simple example

Let's take a non-technical example: "You (the student) e-mail my parents your resume as an e-mail attachment". What are the nouns here? I see

so I'd take these as the classes for (the first) three cards. Let's take these nouns in turn, starting with "You". The only verb you need to make this scenario happen is "send an e-mail attachment", so we'd add that as a responsibility to the "You" card. Note, however, that this activity requires access to two other entities, or collaborators: The document to attach, and the person to send it to (or, more accurately, their e-mail address). This implies that we need two collaborators on the "You" card: The resume and my parents' e-mail address. The first is no problem, since you presumably have access to your own resume. The second, however, is a bit more problematic, since you don't presumably have my parents' e-mail address lying around, and it's crucial that we sort out this gap if we are to claim to have worked through the scenario.

I can see several ways of plugging this gap:

The first option requires access to an appropriate database (i.e., a collaborator) and the ability to search it (a service or responsibility). Both of these are easily managed, making this option at least feasible. The rub, though, is that you still need my parents' names and possibly other information to make sure you get the right address, making this only desireable as a last resort. The second option is easy to implement, although it introduces a new noun ("Me") with it's own responsibilities ("Report my parents' e-mail address"). Note that this also requires that you obtain information you don't strictly need, as the third option gets the job done without you ever getting their address. How much of an issue this is is largely a matter of how sensitive this information is, and how much we trust each other to do the right thing with it. The third option is also easy to implement, but again introduces the same new noun: "Me". In this case, however, my responsibilities are different ("Forward a message to my parents" instead of "Report my parents' e-mail address"). Note that while this case avoids broadcasting my parents' e-mail address, we now have your resume passing through my hands, where I could presumably read or alter it. These sorts of trade-offs of encapsulation are common in object-oriented design, and it's not always obvious what to do. When in doubt, note both possibilities and move on, hoping that something later will help clarify which choice to make.

The results

If I were to take the second option above and write out all the pieces, I'd probably get something like:

You
Send an e-mail message with an attachment to a given e-mail address.

Ask a person for their parents' e-mail address.
Your resume

Me
Me
Report my parents' e-mail address.
 
Your resume
 
 
My parents
Receive e-mail with attachments.
 

Some comments on this solution

Note here that there is much that isn't mentioned because it's not necessary for this scenario. Your resume, for example, has no responsibilities or collaborators in this scenario; it's just a lump travelling about. My parents are also rather boring in this scenario. In a real system there would presumably be other scenarios that introduce other behaviors to these nouns, as well as new nouns. There might, for example, be a scenario where my parents actually do something with your resume, like stick it on their fridge next to our son's latest art work. This would introduce new verbs to their card ("Stick document on fridge"), as well as new nouns to the system ("Fridge").

Note also that we don't need to list something as a collaborator of an entity unless that entity needs to be able to directly access it. In our scenario, for example, my parents and I never need to be able to access anything directly since we're just passive agents processing requests.

While this example may seem silly and contrived, you can change the labels and get a very real example. Imagine, for example, that instead we have a system that generates documents which are then entered into one of several databases. "You" are the entity that generates the document ("Your resume"). "I" am the entity that decides which database the document belongs in and gives you the address (or, perhaps, the password) for that database. "My parents" is the mediator for the given database that receives and processes requests, and the "Fridge" is the actual (possibly remote) database engine where the information is stored.

End of CRC card example

Back to my home page

Feel free to send me some mail:

mcphee@morris.umn.edu

Unless otherwise indicated, all material in these Web pages Copyright 1998, Nic McPhee. These materials may be redistributed provided that this notice remain attached and intact. Under no circumstances can this material be sold or distributed for compensation of any kind without prior written permission from the author.

The views and opinions expressed in this page are strictly those of the page author. The contents of this page have not been reviewed or approved by the University of Minnesota.