This page is excerpted from Chapter 5 of Use Case Driven Object Modeling with UML – Theory and Practice (Apress, 2007) by Doug Rosenberg and Matt Stephens:
Robustness analysis takes place in the murky middle ground between analysis and design. If you think of analysis (i.e., the use cases) as the “what” and design as the “how,” then robustness analysis is really preliminary design. During this phase, you start making some preliminary assumptions about your design, and you start to think about the technical architecture and to think through the various possible design strategies. So it’s part analysis and part design.
Anatomy of a Robustness Diagram
A robustness diagram is somewhat of a hybrid between a class diagram and an activity diagram. It’s a pictorial representation of the behavior described by a use case, showing both participating classes and software behavior, although it intentionally avoids showing which class is responsible for which bits of behavior. Each class is represented by a graphical stereotype icon (see Figure 5-2). However, a robustness diagram reads more like an activity diagram (or a flowchart), in the sense that one object “talks to” the next object. This flow of action is represented by a line between the two objects that are talking to each other.
There’s a direct 1:1 correlation between the flow of action in the robustness diagram and the steps described in the use case text.
The three class stereotypes shown in Figure 5-2 are as follows:
- Boundary objects: The “interface” between the system and the outside world (think back to Figure 3-2). Boundary objects are typically screens or web pages (i.e., the presentation layer that the actor interacts with).
- Entity objects: Classes from the domain model.
- Controllers: The “glue” between the boundary and entity objects.
It’s useful to think of boundary objects and entity objects as being nouns, and controllers as being verbs. Keep the following rules in mind when drawing your robustness diagrams:
- Nouns can talk to verbs (and vice versa).
- Nouns can’t talk to other nouns.
- Verbs can talk to other verbs.
Here’s an example robustness diagram, for the Show Book Details use case (one of the example use cases that we follow all the way to source code, in the Use Case Driven book). Click the image for the full-size version:
Once you’ve completed robustness analysis, you should do a Preliminary Design Review (PDR). The PDR sesion helps you to make sure that the robustness diagrams, the domain model, and the use case text all match each other. other. This review is the “gateway” between the preliminary design and detailed design stages, for each package of use cases. After that, you’re ready to begin the detailed design.