Crc Describes Scenarios

Here's a little playlet showing how CRC can describe a scenario in C3. We're going to describe how an EmployeeProfile? with transaction code 61 causes the employee's progressive COLA (Cost Of Living Allowance) to progress.

DESIGNER makes a card for Person, puts it on the table.

DESIGNER: Each person has a Cola Rate History. (makes a card for Cola Rate History, puts it overlapping the Person card).

DESIGNER: The Cola Rate History holds a historical collection of Cola Rates. (makes a couple of ColaRates? with dates on them, puts them overlapping the Cola Rate History.)

DESIGNER: (pointing to one of the Cola Rate cards) If the employee doesn't get COLA, he has a Missing Cola Rate from Infinite Past to Infinite Future. The Missing Cola Rate answers zero for the rate.

DESIGNER: (pointing to another Cola Rate card) For any period when the employee gets standard COLA, he'll have a Standard Cola Rate in the historical collection. The Standard Cola Rate answers the company standard cola rate.

DESIGNER: (making another card, Progressive Cola Rate) If the employee is on progressive cola, he'll have a Progressive Cola Rate for that interval. That object has its own collection of dates and rates internally, since each "progressive" individual gets his cola rates individually. The Progressive Cola Rate answers that individualized rate.

DESIGNER: The tricky bit is knowing when to progress. It turns out that happens when you get an Employee Profile with code 61. When that happens, you progress the employee's COLA.

DESIGNER: (making a card) We get a Personnel Event whenever there's at least one new profile. Personnel Event reads all the new profiles and adds them to the Person. (makes a Profile card and waves it over the Personnel Event)

DESIGNER: Each Profile is then sent to the Person to be added to his profile. (waves the Profile card over to the Person). The Person already does some special processing: for example, it checks for and handles PAR awards. We'll extend that processing to deal with code 61s. (still waving the Profile over person)

DESIGNER: (puts Profile down on person) If the profile is a 61, we'll just tell the person to progressCola. That will create a new Rate (makes Rate card) and put it in the Progressive Cola Rate, effective the date of the Profile. (puts Rate overlapping Progressive Cola Rate)

DESIGNER: So, when a 61 arrives, the person progresses his COLA and we're all set.

I'm not clear whether reading this will give enough of the flavor: it's the best I can do without an MPEG file. The effect in real life is that by creating the cards as you go, and moving them from place to place as you discuss how they're used and which objects collaborate with which others, the interactions become clear.

Now, how could that be considered an actual design? We have sort of named the classes, and we named one method, progressCola, but we haven't named anything else from the new implementation. In XP, this is not a problem, because every developer knows how to name classes and methods in exactly the same way, so as soon as the developer knows what she is going to do, she's free to go and do it.

Questions?

-- RonJeffries

This doesn't sound like an unusual use of CRC with the exception of all the not-writing-down. It'll be obvious to anyone who's used CRC in a group setting, however, that the dramatic effect of such a session is good for at least an hour's consensual recollection. See BigModelsAreUseless for corroboration.

The best description of CRC scenario capture I've encountered is the role-playing section of TheCrcCardBook, which I'm sure you'll have seen. I'm more curious about the context of your use here - whether you also use CRC to plan refactoring, AcceptanceTests, and EngineeringTask(s), whether there's feedback from your CRC sessions back up to UserStories, and so on. -- PeterMerel

We use CRC to plan any implementation or large refactoring. The flow of the cards might imply an AcceptanceTest that should be written, or suggest a case that should be tested for. CRC, as the plan for implementation, directly leads to engineering tasks: write this object, extend that one, and so on. Sometimes we'll CRC to draw out detail behind UserStories, and once in a while we'll show by CRC that what they are asking for isn't what they want. -- rj

Quick Questions Off Topic: Ron, I'm still not clear on XP's use of CRC sans writing. I think that in your carding sessions when you lay one card on top of another you mean collaboration, but I wonder what happens when you have some complex collaborations that make your cards get higgledy-piggledy - is that when you actually write on the things? I also understand that you sometimes don't write names on the cards - do you distinguish between them by color? Do they sometimes get mixed up then? Perhaps it's time to break out the video camera ... -- PeterMerel
Not writing on the cards is just a shorthand macho trick, not part of our rules. The objects and the story are the point: you do as much or as little writing as it takes. If there are more objects, we're more likely to write, or if we know the area less well. Trying to use color consistently is usually a waste of time, though sometimes we'll use a different color (once even different size) for objects of which we want to lay down a lot. This is rare.
Quick answer to check my understanding: Last time I saw Ron do this, moving the cards around (laying them on one-another and any other manipulations you care to think of) meant what he said they meant while he was moving them around. In one case, laying one card on top of another represented moving responsibility from one object to another -- the card laid down represented the responsibility while the target card represented the class that should have that responsibility. Another card represented the class the did have it but shouldn't. I've watched Ward more often than Ron, and Ward has a tendency to write classnames on the cards. They then more firmly represent classes, and laying one on the other represents some form of association or collaboration, though what specifically that is is not captured in the cards but in the accompanying narrative. The point of the exercise is helping us all understand what we are talking about. -- BillJamison
Ward was going slower than I was (I was going too fast for the situation). Ward is much more pedagogical than I - I'm used to working with them more than teaching with them. -- RonJeffries
So you did it wrong??? My my... So the point of the exercise is narrower than helping us all understand what we are talking about? -- BillJamison
In my evaluation after the fact, Ward and I were addressing two different things. The original question was "should this class do X". I was answering the question and showing from the cards why the answer was as I thought. Ward was showing the group how to answer questions like that for themselves. Different objectives. In retrospect, Ward's was a better objective. I gave you a fish, Ward cooked it. Or something. -- RonJeffries

(Reading this, I see that Ron did it differently. I don't get a "wrong" out of it. -- AlistairCockburn)

Actually, I don't either. Ron's comment seemed to imply that I was over-generalizing from my single data point (I've not been able to work with Ron as much as I would like). An (not the only, or the best) interpretation of that is that he didn't do it right. I was trying to provoke a direct comment about my generalization in a small space (I find that I write far too much trying to state my point). You and Ron are right, however, in that the things Ward and Ron did were different. I agree with Ron that Ward's goal was better -- at least two of us walked away from the table with a lot more than we came with.

-- BillJamison

Moved from WhatIsaScenario

In OnePieceOfPaper, scenarios are referenced. What are they?

A Scenario is a sequence of events that is expected to happen as a system gets used. In my context of marine radar an example might be a vessel entering a reporting zone, providing its details by VHF radio, manoeuvering around a buoy, anchoring for a time, then approaching the port and docking. We use several dozen of these to demonstrate the facilities our system offers.

By running through the scenarios we are providing one form of system test. In contrast, a FAT (Factory Acceptance Test) or SAT (Site Acceptance Test) generally consists of a list of features that must be demonstrated. By running the scenarios first the customer can simply mark most things as done. Then individual features can be checked as necessary.

CategoryCrcCards