CRC Cards Reloaded

 

I've been doing some high-level architecture work in multiple settings over the last weeks. By "high-level" I mean thinking about the components in a system and allocating their reponsibilities and interactions. CRC cards are quite well suited for figuring this out. CRC is short for class-reponsibility-collaboration, and they have originally been introduced by Ward Cunningham and Kent Beck. You basically name the components (or classes, or whatever) in your system, list how each one contributes to the overall system functionality, and specify which other components they collaborate with, and how. It's basically a high-level, informal class diagram.

 

The work I was doing was collaborative of course: multiple people contributed to the architecture. So we decided that we'd create our CRC "cards" in a Google Doc, simply as a bullet points with the following structure:

 

 

So far, so obvious. As we worked on this stuff, we found that we needed additional info for the components:

 

 

Each of those can be attached to (ie., written below, indented) a component, responsibility or collaboration. Using these additional categories, we were able to quickly create a quite rich but still structured description of what would be going on in the system. Because it is all textual, things can be changed easily, and because it was all done in a collaborative document, every participant in a (remote) workshop can contribute directly.

 

This is obviously not rocket science. Quite likely somebody else had this idea of CRC++ before. I am sure that outliners or mind mapping tools can categorise things in that way. However, I find this approach really quite useful for structuring a system. In particular, I find it much better in early stages of design than directly drawing a class diagram because it is easier to (collaboratively) edit.

 

But: the information contained here can of course be easily mapped to a class diagram:

 

·      Component: a class

·      Responsibility: a method

·      Collaboration: an association

·      Specialisation: inheritance

·      Variant, Rationale, Question: comment note

·      Example: a class with some stereotype

 

Which is why I have written a little Ruby utility that does that. It takes markdown of the above structure and transforms it into PlantUML class diagram syntax. Find it here on github. It's a prototype right now. If you want to help make it better, ping me :-)

 

Update (Feb 22): here is an example of a rendered class diagram.

 

No alt text provided for this image