Author Topic: CRC cards (Read 11881 times)

JohnDoe · « **on:** July 28, 2009, 08:52:11 pm »

Hello,

is there any alternative to CRC cards in EA ?

Greetings
Bernd

JohnDoe · « **Reply #1 on:** July 29, 2009, 07:05:34 pm »

No idea anyone ?

Geert Bellekens · « **Reply #2 on:** July 29, 2009, 09:38:30 pm »

Maybe if you explained what CRC card are, and how you use them, there might be some people who have helpful suggestions.

Geert

Makulik · « **Reply #3 on:** July 29, 2009, 09:56:24 pm »

Hi Bernd,

I think the most appropriate UML equivalent to CRC cards are class diagrams and collaboration diagrams. May be you can also use Use Case descriptions on class level, to have a more conceptual description of the responsibilities and collaboration paths of your classes.
In general CRC cards have a completely different approach to OO-design than UML. Especially CRC cards are intended to be physically present cards, instead of having a design repository as an electronic document. That's mentioned as an essential aspect when the CRC card concept was described by it's originators Beck and Cunningham.

HTH
Günther

«Midnight» · « **Reply #4 on:** July 30, 2009, 02:01:32 am »

Just thought I'd toss in another 0.02 CAD...

Jacobson and Rumbaugh both discussed them (CRC Cards) in the early days, before and during the inception of UML (0.x). So of course did other practitioners - beyond those who directly contributed to early UML - around the same time. These latter include such names as Shlaer, Mellor, and Wirfs-Brock. There are many variations on the theme among these writers, but the core concepts hold up pretty well.

All that aside, CRC cards were a pretty good way of keeping various concepts - including Classes, Responsibilities and Collaborations; thus the name - straight during the early stages of object modeling. To a great extent, at least in the context of Jacobson and Rumbaugh, UML is a descendant of (the methodology that includes) CRC cards. So one could say that the various structural models within UML fill much the same function with additional features.

Of course a simple listing of the concepts involved still has its uses. Most UML tools provide reports that serve this purpose on output. Some provide straightforward input methods to 'bootstrap' a model from something like a CRC card; some even replicate the paradigm of the card for this purpose. EA is pretty good on the output side. On the input side it could use some work. Of course there are other means to bootstrap a model, and EA provides support for some of these.

David

JohnDoe · « **Reply #5 on:** July 30, 2009, 04:11:19 am »

Staying with iconix, I would start with a visual glossary of elements. But after that, I would like to start clustering objects according to Wirfs-Brock "object design".

This means: The initial glossary will be enhanced by introducing responsibilities and associated classes.

Another way to start is, to write down user stories and requirements and start modeling from there.

Anyway, CRC cards are a very simple to understand concept outside the PC in the real business world, which I would like to load into my EA models after a design session with my clients.

Since CRC cards are something that business people can "grip", they get lost as soon as I present class diagrams afterwards.

Of course, class diagrams are compatible with CRC cards at some point. But this is one step further in the process.

Beside writing user stories and CRC cards in Word and Excel and putting them in Artifacts, is there any other way to "import" CRC card information into EA models ?

By the way: I usually elaborate the class diagram after a glossary session, a CRC card session and sequence diagram sessions. The class model is the result, not the input.

Greetings
Bernd

Makulik · « **Reply #6 on:** July 30, 2009, 07:13:37 pm »

Hi Bernd,

OK, this elaborates a bit more what you plan to do.

If the results of your CRC cards session are coming from a discussion with the customers and describe the things on problem domain level, I would try to "import" the information building up use case models. This kind of diagram is usually better to present to business people and customers, than the more technical oriented class diagrams (you're right, that's one step further).

WBR
Günther

JohnDoe · « **Reply #7 on:** July 30, 2009, 09:05:17 pm »

The issue with useCases is, that they are excellent to describe monolithic entities. But when discussing with clients, you wont stay in one area. Customers tend to tell you everything about anything. It is important to collect all that information. CRC cards are very good to write down hints, collect information and elaborate responsibilities.

Therefore I would like to take these cards into EA and start form there.

Dave_Bullet · « **Reply #8 on:** August 03, 2009, 07:40:25 am »

Class = UML class in EA
Resposibilities = Notes of the particular class
Collaborations = UML associations with other classes

The card becomes a report that you can hand to people. Lookup RTF templates and build a template that lists under each class its responsibilities and a list of classes it is associated with. You can get the relationships via the "connector" element in the RTF template, where you can print the target element name from the connector.

You could build a webpage that dynamically allows people to change the class, responsibilities or its relationships via direct edits on the EA database. We have done this approach for enterprise modeling where we allow non EA modelers to edit application, database and server relationships via our Intranet and ASPX pages.

Cheers,
David.

JohnDoe · « **Reply #9 on:** August 03, 2009, 08:46:54 am »

sounds interesting.
thanks for that idea.

«Midnight» · « **Reply #10 on:** August 04, 2009, 07:37:48 am »

Quote

Class = UML class in EA
Resposibilities = Notes of the particular class
Collaborations = UML associations with other classes

...

FWIW...

I have seen a similar take on this which works as David suggests, with the following change:
Responsibilities = Internal Requirements

UML is fairly flexible on how internal and external requirements fit into a model. Given that the CRC card methodology is not fixed in stone, the two paradigms can be made to cooperate quite well through internal requirements (on the UML 'side' of things). In the case of EA this frees up the Notes field of structural entities to once again become general notes.

Of course there is a small amount of effort required to incorporate this change into reports. This requires some custom template editing, but should not be onerous.

Paolo F Cantoni · « **Reply #11 on:** August 05, 2009, 10:28:36 am »

I agree with David (Midnight), EA's Internal Requriements are best thought of as the responsibilities of the item. Indded EA is itself schizophrenic about what they are... (See Set Feature Visibility|Show Element Compartments).

What would be nice is to have a rendering option to render the classes as CRC cards... Although you can go par tr of the way by careful management of the Set Feature Visibility options above.

HTH,
Paolo

JohnDoe · « **Reply #12 on:** August 05, 2009, 04:14:08 pm »

>>> What would be nice is to have a rendering option to render the >>> classes as CRC cards

I second that.
Maybe this could be done using a custom MDG toolbox, visualizing classes as CRC cards !?

Greetings
Bernd

Luis J. Lobo · « **Reply #13 on:** August 05, 2009, 05:40:06 pm »

Create a <<CRC Card>> stereotype and assign a "shape script" to it.

JohnDoe · « **Reply #14 on:** August 05, 2009, 06:30:50 pm »

Hmm. Do you mean, creating a new MDG technology and adding a stereotype and a shapescript and creating that MTS-File and reimporting it, or is it possible to add a stereotype with custom shapescripts to the EA stereotypes somewhere in the EA menu ?

Sparx Systems Forum

News: