Chapter 4 - Getting up to Speed

Finishing the user stories with the client... allocating user stories to project iterations... working on the architectural baseline... thinking about your team...

Robustness Diagram

Hi there!
What is a Robustness Diagram?
I haven´t found info in the wikipedia (there are other sourcers too, like Google:
Maybe that´s something very basic that all prgrammers should know already. I think that the robustness diagram, is part of the agile development concept, am I right?
You´ve mentioned "death to Visio" somewhere, but isn´t those diagramas some sort of "related" thing?

Maybe I´m skipping something basic here, and the question is pretty silly, but I would like to know about the differences between this diagram, and, let´s say, the meme map.

Robustness diagrams are the best thing since sliced bread

OK. A couple of things here. The Agile approach is often criticized for "not doing analysis and design". This is completely wrong. It's that with the Agile process analysis and design become part of the implementation micro-cycle of a single use case. And it is not necessarily documented in learned tomes that later are of no use to anyone (unless of course you want to).

But it's there all right, and guess what? It's not some abstraction done weeks or months ago before all the requirements changed: it's done on the basis of the user story you are implementing with the client right now.

So, even though Robustness diagrams were originated as part of the Iconix process an ancient pre-Unified Process methodology, and there is a great explanation on their site, the best discussion today is to be found on Scott Ambler's Agile Modeling site (see table of contents lower left):  Scott gives a great explanation there:

By drawing a robustness diagram we quickly gain a sense for the work that we need to do to implement [the requirements].

It also is a great way to check (test) the semantics used in the User Story and to drill down to what I call in Leveraging Drupal "finding a common language". Then nouns used by the client may need to be made more specific and/or objectivezed before they find themselves incarnated as block titles, menu items, or script variables.

The robustness diagram tests this, since it is a first cut of business objects which will form the basis of support for the implementation of the user story.

As you draw robustness diagrams during the implementation of each user story, you are mapping out the domain of all the business objects, and gradually mapping that to a Drupal core and contributed module based architecture.

There's a lot of room for discussion here, but I left it as a point of further exploration, not beyond the scope, but on the frontier of most readers of Leveraging Drupal.

ups old discussion

just some points:

  • robustness diagrams were not oroginated in Iconix but in Objectory method by I. Jacobson. I hope I gave the credit where it belongs ;) It looks astonishing that one of the founders of UML didn't push it through, but I guess he had a reason, because
  • you can explain the same behaviour with the so called 'system sequence diagrams' (SD are more generic, what might be confusing), i.e you don't need another notation. This is from the developer/architect POV. From customer POV the robustness diagram is more conscice and less shocking than the sequence one, though.

Iconix really popularized robustness diagrams

in a very practical way, and breached the huge gap between use cases and sequence diagrams (between analysis and the inception of design).

Because one of their functions is to "find a common vocabulary" and refactor model semantics as one unifies terms simultaneously between use cases and pre-sequence diagrams.

For this reason they are not the same.

And many of us learnt that from Iconix.

Thank you so much for enriching the dialog on this subject,


You're welcome

Btw I found this site again ;-)

My reaction was not meant as criticism in any way. I'm sorry if it looked so. I'm using ICONIX now, and I've been using RUP before. I guess I said 'are the same'... then I do apologize.

The truth is, when one reads the Larman's book on RUP, it will teach him to work out systems without the Robustness diagrams. On the other hand is the Rosenberg's book on ICONIX, which almost doesn't need the sequence diagrams - exaggerating a bit, but the robustness diagram is 'doing the main work' and the sequence diagram is there just to see the call order etc (and information about time)

ICONIX uses the RD to 'verify' and 'explore hidden things in' the domain model and use cases text. First it does the domain model, then use cases, then robustness to clarify the UC and DM ... all iteratively.
Rup on the other hand does first the use cases, where you have some rules while creating them. Then it does use the system sequence diagrams (on system level, so you will have some entities and controllers there) and domain model iteratively together. So one uses the system sequence diagrams with the responsibility assignment rules to identify domain objects and assign responsibilities of 'knowing' and 'doing' to them.
I.e, in the Rup, the system sequence diagrams help to 'verify' and 'explore hidden things in' the domain model and use cases text(which you correct back). Off course sequence diagrams do not do it alone - there are rules of responsibility assignment and rules for writing use cases too. When I added it together, I found out that those are all the concepts behind the robustness diagrams.
But, I might be very well wrong. :)
Good luck with the book if it is still in the making.

Right! The key is to 'verify' and 'explore hidden things'

I hear you. The process of working with the domain model and system sequence diagrams do the same job of finding a common vocabulary (testing the semantics) and bridging the gap between use case text and analysis abstractions, that robustness diagrams do in ICONIX.

The main thing is to get things done.

I enjoy your comments, thank you so much,

Victor Kane

My pleasure

Thanks for the discussion

Ed Toth

Thank you!

Thank you for your clear explanation Victor!
And thanks for Scott Ambler's site reference! It´s great!

Where are the user stories?

You mention a complete list of user stories existing in the chapter download, but I was unable to find it in either the code only or complete download. Is it a separate document or am I looking for the wrong thing?

Check out the code to Chapter 11

Chapter 11 has all the user stories written up. Sorry about that, I will post this in my notes to Chapter 4.

Just install it and click on the left-hand side user stories link (logged in as dev/dev). You can also find them online at

Thanks so much for pointing this out.

User Stories

Hi Victor, working through your book here. Can I get to the user stories at without logging in? If not, is there a public user we can use? Or should we all "Join" and apply for membership? (I don't want to install the codes from Ch.11 just to get the User Stories, I want to go through the whole book, step by step.)



You can log in as follows:

user: userstories
password: userstories

Then click on the user stories link in the Project block to be taken to

You can then filter the list of user stories by iteration.