Analysis, design, and never the twain shall meet

Jumping the chasm

So the goal of preliminary design is to turn your use cases into something much more concrete: to eliminate ambiguity, turn passive voice descriptions into active voice, separate out any functional requirements that may have slipped into the use case text, and to discover missing requirements. To do this, use a technique called [drum roll please...] robustness analysis. Not many people have heard of it; in fact it’s one of the industry’s best-kept secrets, but it works. Robustness analysis involves drawing a picture of your use case, using three UML-esque elements: boundary objects, entity objects, and controllers (logical software functions). It’s all very MVC, and is great for creating the preliminary design for web applications.

The key is to write the use case text in the context of your domain model, and reinforce this relationship on the robustness diagram. So if the domain model has objects called “Book” and “Shopping Cart”, in your use case you wouldn’t write “The user selects a stock item to purchase”, you’d write something more concrete and specific, like “The user clicks to add the Book to his Shopping Cart”. Book and Shopping Cart will both become entity objects on your robustness diagram; and “add to Shopping Cart” will become a controller, as it’s an action - a verb.

Robustness analysis is great as a sanity check: if your use case doesn’t translate well onto a quick n’simple robustness diagram, how in the blazes will you be able to create a solid design from it?

The technique also has an interesting, and useful, effect: it turns your use cases into nice compact, unambiguous units of behaviour that are easy to design from, easy to estimate, and easy to write unit tests for (you write one unit test class per controller).

This has been a high-level summary, of course. But in future articles I’ll explore different parts of this process in more detail, as well as exploring different aspects of software agility with a critical eye.®