Original URL: https://www.theregister.com/2007/12/14/robustness_analysis_book_extract_3/
Close the gap between analysis and design
Get robust
Posted in Channel, 14th December 2007 11:14 GMT
Book extract, part 3 To get from use cases to detailed design (and then to code), you need to link your use cases to objects. The technique we describe in this chapter, robustness analysis, helps you to bridge the gap from analysis to design by doing exactly that.
As in our first two extracts (here and here), let's start by mapping where we are in the ICONIX process. This time, how robustness analysis fits into the process.
Robustness analysis - brings it all together
Robustness analysis in nutshell is a way of analyzing your use-case text and identifying a first-guess set of objects for each use case. These are classified into boundary objects, entity objects, and controllers (which are often more like functions than objects) - see the next diagram for more.
A robustness diagram is an object picture of a use case. The robustness diagram and the use-case text have to match precisely, so the robustness diagram forces you to tie the use-case text to the objects. This enables you to drive object-oriented designs forward from use cases, and this is really the "magic" of robustness analysis.
Robustness diagram symbols
Like learning to ride a bicycle
Learning this technique has a bit in common with learning to ride a bicycle. Until you "get it", robustness analysis can seem devilishly difficult, but once you do get it, it's really very simple.
To jump-start your understanding, we'll walk through plenty of examples in this chapter. Experience has shown us that you usually need to draw six or so robustness diagrams before the penny drops and you suddenly get it. Just remember, a robustness diagram is an object picture of a use case.
Once you get the hang of it, you should be able to rattle off a robustness diagram in about 10 minutes (or less) for each use case. Actually, as you'll see, the trick is in writing your use case correctly. If a robustness diagram takes more than 10 minutes to draw, you can bet you're spending most of that time rewriting your use case text.
Updating your domain (static) model
Our next diagram shows the updated static model for the internet bookstore we are building, following robustness analysis for the "Show Book Details" and "Write Customer Review" use cases. The added or updated classes are shown in red.
Static model for the internet bookstore, after robustness analysis for two use cases
Robustness analysis in practice: take the test
As with our previous extracts, it's time for a quiz. This time, there's no top-10 list, but - instead - a visual puzzle. The robustness diagram excerpt (shown next) highlights a number of errors, including at least one in the use case text, in the last sentence of the basic course, and two where the text and the diagram don't match up. Have fun finding them all.
Spot the error - what's wrong with this diagram?
Did you spot the problems? Overall, the diagram doesn't match the description. Digging deeper, the first mistake is that the text starts at an earlier point in time than the diagram (a common mistake). An easy way to spot this type of error is to use the highlighter test.
The second error - the GUI widget is shown as a boundary object - is another common mistake. A GUI widget such as a button is too fine grained to be the boundary object; instead, the boundary object should be the screen or web page.
The third is fundamental: an entire chunk of the use-case text has been left off the diagram. It's surprising how often this happens. It's usually a sign that somebody isn't working through the use case one sentence at a time.
Our fourth and final problem is a direct consequence of ambiguous use case text. The text wasn't tied closely enough to the objects, so the modeler just sort of went off in a pseudo-random direction and, lacking the real boundary object to work with, used "Select address" as the boundary object, even though it's a verb and, therefore, is a controller masquerading as a boundary object. And as we're sure you know by now, actors can't talk directly to controllers.
Seeing red - mistakes highlighted
In redrawing the diagram, shown next, we discovered another ambiguity in the text - funny how that happens!
The text "the system displays the Delivery Address page showing any addresses already registered for the user's account" implies some search and retrieval initialization behavior, which currently also doesn't appear anywhere on the diagram.
So we rewrote this part of the use case and added it into the diagram, and in the process we discovered another domain class (Delivery Address List). This is exactly the kind of scenario where robustness analysis proves invaluable - discovering hidden functionality and missing domain classes, just in time to begin designing.
The corrected robustness diagram
In the fourth and final excerpt from our book, we'll take a look at detailed design using a minimalist approach to sequence diagrams.
Use Case Driven Object Modeling with UML: Theory and Practice is available for purchase through Register Books, at the special price of £34.99. ®