Introduction

Objects by Design is pleased to bring our readers this interview with Rebecca Wirfs-Brock, a well-known author and consultant in object-oriented software design and development. Her recent book, Object Design (Addison Wesley - November, 2002), is a nice blend of her insights into such topics as CRC Cards, Collaborations and Flexibility, the topics of our interview. The book comes highly recommended because of its unique, fresh insights, which our readers will surely appreciate. If you have any feedback on this interview or the book, please post a message on our forum thread .

CRC Cards

SZ: CRC cards have been around for a while now. Kent Beck and Ward Cunningham delivered a paper at the OOPSLA '89 Conference that introduced CRC cards. I know that you have been a big proponent of CRC cards yourself. Are you still finding them quite useful in your work? Why haven't UML tools provided any support for CRC cards? Is this because they do not fit into the UML notation?

Rebecca Wirfs-Brock: We mostly use CRC cards in our training (and occasionally in analysis and design work). And yes, they are quite useful. Especially for describing the essential characteristics and behaviors of a candidate object.

In the olden days, CRC stood for Class-Responsibilities-Collaborators. In my current line of thinking I use the first C to stand for "Candidate" and make a conscious effort to not make each card stand for a class. I think with support for defining interfaces that are realized by classes, that we have an opportunity to make mapping decisions to implementation and shouldn't get hung up too early on whether a "candidate" is a class or a role that can be implemented by several classes.

I am not as dogmatic about using physical cards to model so much as I am dogmatic about expressing responsibilities and collaborations and roles of objects at the right level of abstraction. CRC cards are a good way to keep things succinct and to the point. So I quite comfortably model CRC card-level descriptions of object models using whiteboards, and then translate these descriptions to tables in MS Word or even to classes in my clients' favorite design tool. However, the translation between a descriptive responsibility and its representation in your favorite modeling tool isn't always straightforward.

You ask a good question: Why haven't UML tools provided any support for CRC cards? I would prefer to rephrase this as why haven't UML tools provided good support for expressing the behavior and characteristics of model elements at different levels of abstraction. I think this is because most tools (especially those supporting roundtrip engineering) are focused on providing an implementation level view of a class. Fowler talked about three levels (sure there could be more, but this is good enough to get the idea) of abstraction: a conceptual view, a specification view and an implementation view of your design. Well CRC card-level descriptions are especially good for a conceptual view. And I think most tools which are focused on turning your specification into an implementation don't see the value (or perhaps don't have a clean way to support) overlaying these different views onto a design. I wish they did and I'd be happy to work with tool vendors to get them to support different views.

I know my clients would sure appreciate this capability in tools.

SZ: Can you clarify what you consider to be the essential elements of a "conceptual view".

Rebecca Wirfs-Brock: Sure. A conceptual level view of an object design describes the key abstractions. While someone might think of key abstractions as being nothing more or nothing less than high-level descriptions of "candidate classes", I prefer to consider a conceptual design from a slightly different angle--I'm thinking about design at a slightly different level.

An object-oriented application is a set of interacting objects. Each object is an implementation of one or more roles. A role supports a set of related (cohesive) responsibilities. A responsibility is an obligation to perform a task or know certain information. And objects don't work in isolation, they collaborate with others in a community to perform the overall responsibilities of the application. So a conceptual view, at least to start, is a distillation of the key object roles and their responsibilities (stated at a fairly high level). More than likely (unless you form classification hierarchies and use inheritance and composition techniques) many candidates you initially model will map directly to a single class in some inheritance hierarchy. But I like to open up possibilities by think first of roles and responsibilities, and then as a second step towards a specification-level view, mapping these candidates to classes and interfaces.

SZ: Try to describe a concrete way in which a UML tool could support CRC cards. For example, would it be useful to be able to print out CRC cards with the 3 elements of information: Name, Responsibility, Collaboration?

Rebecca Wirfs-Brock: I can think of one way - don't insist that I have to specify a class or an interface (UML calls these classifiers) always concretely in terms of operations  (or in the case of a class- its attributes as well). Let me specify the behavior of a class or interface in terms of its responsibilities (statements about what it knows or does) in addition to that next level of detail- the attributes and operations. Printing out CRC cards might be handy, but more importantly, I think that there should be supported ways to describe your design in terms of roles and responsibilities. UML has a pretty weak concept of role (the name on the end of an association line is it... but that is too limiting a view- a class implements one or more roles, and it would be handy to specify all those roles it plays---instead of having to divine this by looking at links).

Another thing I'd look to tools to provide is a way for me to keep track of unassigned responsibilities and to allow me to specify those things I often put on the other side of a CRC card- a statement of a candidate's purpose, its role stereotypes, and the pattern roles it may be picking up). But I digress. To sum up my answer to your question, I'd rather see UML tool vendors integrate responsibility driven design concepts into the overall way to express a design than add CRC card templates. It's more important for me to capture my initial responsibility-driven design thinking and continue to weave them into the ongoing design than have tool support for 'card-level' views. That's kind of counter to the value I find in using hand written CRC cards--they are informal, they are works in progress, and you can write whatever thoughts you want on them. Tool generated cards wouldn't be that flexible.

Collaborations

SZ: Your discussion in the book on collaborations focuses on the value of walk-throughs. One of my most successful OO projects did thorough walk-throughs of all the collaborations before any code was written - and it was enjoyable! Agile Software advocates whiteboard sessions which are great for collaboration walk-throughs. How do you make these sessions happen and are you finding them successful in practice? In what way could UML tools be more helpful in collaboration walk-throughs?

Rebecca Wirfs-Brock: Getting collaborations sorted out (and developing a consistent control style design) is critical to the success of most design efforts. I like working on collaboration modeling. If you think you're just being arbitrary about whose collaborating with whom (and why), then you probably haven't gotten any real benefit from your modeling efforts A lot of people don't have a set of guidelines that drive them to make collaboration decisions... so they're stuck with what seems to them rather arbitrary partitioning of responsibilities among collaborators. I have lots of guidelines I like to apply, and also a strongly held belief that a delegated control style, when it leads to clarity and simplified interactions, is a good thing.

One thing I think that tools are lacking in is ways to facilitate collaboration modeling, or better yet, to facilitate telling the appropriate design stories, once you've decided on a collaboration model. I would really love it if a tool allowed me to set up a collaboration (by pre-loading specific test cases), then allowed me to "run a collaboration" and take a snapshot of the interactions between objects at just the right level of precision. This would be so much better (and more accurate) than faking my objects' interactions and then drawing illustrative pictures. Why not have tools that allow me to prototype a little, set up a collaboration, then help me document the results.

I've gone into organizations where the amount of diagrams they think they must draw in order to illustrate object collaborations seems daunting. Usually I dispel the belief that more diagrams means better design, and that the key to making a design understood is knowing what to tell (and what to leave out). People should realize that there is much more compact ways to communicate design choices than to draw lots and lots of pictures that look nearly alike. Dressing up a representative collaboration diagram with a chart or table explaining the exceptional cases, how they are handled, and the consequences on the users, for example, is far more effective than drawing 30 diagrams. A picture isn't worth 1000 words if it is mind numbing and it doesn't convey the right information.

SZ: Recently patterns have helped software developers organize the communication about their work in productive ways. Have you thought about organizing your collaboration strategies into patterns to make them easier for people to learn and adopt? I believe this is uncharted territory that could really be developed. Larman has his GRASP patterns which are a good start but nobody has taken this further.

Rebecca Wirfs-Brock:Your suggestion about recasting our collaboration strategies into patterns is an intriguing one. Larman's GRASP Patterns (General Responsibility Assignment Patterns) give very straightforward criteria for assigning objects responsibilities for creating other objects, handling events, decoupling objects from each other, etc. Underlying all these patterns are good design principles. I especially like the way I've seen GRASP patterns cast as a series of questions. There is much to be said for distilling design principles (especially for designing inter-object collaborations) into a set of design questions. I think there are several patterns lurking in the discussions in our book of well-formed collaborations, typical collaborations between role stereotypes, recovery strategies, and trust boundaries. Now all I have to do is come up with evocative pattern names and a clear set of questions to ask and tensions to be balanced.

Flexibility

SZ: The chapter on Flexibility is very well done. Could you explain how to design flexibility into software? What are some of the success stories you have had with clients when designing for flexibility?

Rebecca Wirfs-Brock: Thanks. I had a lot of fun writing that chapter. Flexibility is not easy to specify nor is it easy to implement well. I have had a number of successes with clients helping them both with articulating the point of flexibility they need to have, and then designing a reasonable solution that allows them to expand their software's capabilities to flex.

The key to building in the just the right amount of flexibility involves three main points: understanding what precisely needs to flex, understanding who is going to make the software adaptation (is it an end user, a developer, or someone in operations support modifying data descriptions that the software has been designed to read and interpret?), and then giving those making the adaptation the right "knobs to turn" to make the software flex. Sometimes you might need to build tools and design extra software fixtures that allow people to make a constrained adaptation, sometimes you might have to write recipes that tell how to make an extension.

Flexibility doesn't come for free, just because you are using object technology or applying design patterns. It always involves extra cost, and introducing flexibility often makes software more complex. So I get great satisfaction out of wading through actual needs and proposing the simplest, most cost effective solution to a "flex point". In this world where people can't afford to make too many "expeditions" into building the wrong flexibility into a system, it is really important to understand how much to make a system and then design reasonable solutions.

SZ: Our readers like real-world examples. Can you give some details on a flexibility solution that you were able to help a client develop?

Rebecca Wirfs-Brock: I spent 2+ years as an architect/designer/mentor on an application integration framework for a telecommunications company. The system was implemented in GemStone/J (a Java applications server) and put into production. This system was designed to flexibly integrate billing, order taking, provisioning, and provisioning planning applications.

The basic idea is very simple: instead of connecting each of these applications directly to each other, our software was in the middle. The goal was to provide business value by enabling the telco to integrate new applications and support more sophisticated process integration. We had to contend with multiple billing systems, multiple order taking and customer service applications, and different provisioning systems.

As part of this project, I wrote up a "hot spot" document that described the major areas where we wanted our software to flex. This was only the beginning. There were many points of flexibility in the system. But the major starting point was the overall architecture. The system was partitioned into adapters that interfaced with the "core" of the system, which had the major responsibility for coordinating work in each integrated application (as the result of receiving and processing orders). Each adapter was responsible for transferring requests and information between external applications and the core.

We defined a general mechanism for defining business processing tasks involved with placing, modifying and canceling orders. We developed a declarative model of products and billing. We defined a common set of commands to communicate between the core of the system. We defined mechanisms for locating resources maintained in these external applications. Most of the time we didn't have pre-existing architecture patterns to fall back upon. So we had to innovate while keeping true to our design goals. It was a lot of fun to work on many areas of the design. More importantly, it was successfully put into production.