PDR should involve representatives of both the customer(s) and the development team, as well as any necessary managers, just like requirements review. There’s a key difference, though: this is the last chance for the customer to change requirements before the developers drive the given set of use cases through to code. You can think of PDR as representing a line beyond which customers are no longer welcome to actively participate in the process. We talked previously about how use cases represent contracts between customers and developers; it’s during PDR that you finalize those contracts.

As we described in Chapter 5, robustness analysis provides a sanity check by helping you make sure that your use case text is correct and that you haven’t specified system behavior that’s unreasonable—or impossible—given the set of objects you have to work with.

This refinement of the use case text changes the nature of that text from a pure user manual perspective to a usage description in the context of the object model. PDR should center around peer review of all use case text and robustness diagrams. Each reviewer should be able to do the following for each use case.

Figure 5-5 shows the rules of robustness analysis. Given that both boundary objects and entity objects are nouns, and that controllers are verbs, we can see that nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs. The goal is to itemize all the required behavior of the use case in the form of control objects (controllers). This involves taking the user manual view and identifying all the logical functions that must occur, then massaging the narrative of the use case text into a straightforward noun-verb-noun format. This format will allow us to check for correctness when we embark upon detailed design by ensuring that we don’t forget any behavior while we’re doing the design. Doing this also helps enforce a common noun-verb-noun style of writing use cases across a design team.

As we just mentioned, the verbs in your use case text are represented as controllers on your robustness diagrams. These controllers encapsulate the control flow, and they serve as the “glue” between boundary objects and entity objects, between boundaries and other boundaries, and between entities and other entities. Remember that the reason we call them controllers, rather than control objects, is that they serve as placeholders—we’re not ready to assign the behavior they represent to any objects yet because we don’t have enough information. Decisions about which methods go on which boundary objects and entity objects, and also about which controllers deserve to become full objects in your static model, are premature; we make them during sequence diagramming, not on robustness diagrams.

Arrows can go in one or both directions between different types of objects on a robustness diagram. An arrow pointing from a boundary object to a control object indicates that the former is signaling the latter to perform. Or there might be a two-headed arrow between a control object and an entity object, signifying that they read from each other and write to each other. Note, however, that you need to use only one type of arrowhead, which is not the case on several types of UML diagrams. Unlike arrows on sequence diagrams, arrows on robustness diagrams don’t represent software messages; rather, they simply indicate communication associations. Because you won’t code from these diagrams, focus on the logical flow of your use case and worry about the directions of arrows later, in your sequence diagrams.

You should, however, be aware of the presence of patterns across robustness diagrams. Patterns often start becoming visible during robustness analysis. There are two strategies, “control in the screen” and “use case controller,” that lend themselves to discovering patterns connected to use cases. (See Use Case Driven Object Modeling for details about these terms.) Looking ahead to interaction modeling, design patterns can be highly useful in the context of sequence diagrams and design-level class diagrams. You should not, though, start drawing full design patterns on your robustness diagrams; it’s sufficient to start thinking about how you’ll be able to use them to advantage during detailed design.

We used the term technical architecture at the beginning of the chapter. This refers to the set of basic decisions you need to make about what technologies you’re going to use in implementing the system. These decisions involve things such as the programming language (for instance, Java versus Visual Basic) and how you’re going to build and distribute software components (will you go with Enterprise Java Beans [EJBs] and Java Server Pages [JSPs], or take the Microsoft route with Distributed Component Object Model [DCOM] components and Active Server Pages [ASPs]?). The decisions you make about your technical architecture need to be reflected, to some extent, on your robustness diagrams.

If, for instance, you’re building with a technical architecture that involves EJBs and JSPs, your robustness diagrams will tend to reflect the “control in the screen” pattern more than they would if you were building pure HTML pages. Thus, robustness analysis, which is meant to give you a loose description of the design that you can crank out quickly, offers the chance for you to verify that your technical architecture works for the scenarios you’re building, and your review of these diagrams becomes a “do-ability” check on that architecture.

Continuing the thought about patterns: The concept of throwaway diagrams is useful in connection with preliminary design; it is not a useful concept when it comes to detailed design. Sequence diagrams are the appropriate place for detailed design. Robustness analysis should be a quick pass across all of the scenarios you’re going to build, in order to provide maximum value to your project. If your preliminary design takes as long as detailed design, you’ll lose the benefits of this quick sanity check.

Robustness analysis allows you to make a reuse pass through the entire use case model before you commit any use cases to the design. Looking for reuse possibilities also helps you identify objects you missed during domain modeling. You must update your static model before you can consider yourself done with robustness analysis and ready to move on to interaction modeling (the subject of Chapter 7). The new objects you discovered while you were drawing all those robustness diagrams and talking about them with your customers need to go onto your class diagrams now, not later.

This is also the right time to add some key attributes to your more significant classes. While we’re talking about attributes: As we introduce windows and screens—in the form of boundary objects—to our robustness diagrams, we begin to trace data associated with those objects back to the entity objects from which the data comes and/or to which it goes. The natural result of that tracing is the addition of attributes to the classes in the domain model.

The flip side of the principles we just discussed takes the form of a number of common errors that our students make when they’re doing preliminary design review for their projects. Our “Top 10” list follows.

Robustness analysis is where use cases get tightened up and the development team gets ready to jump into detailed design. Your goal should be to have iron-clad use cases in place before you start drawing sequence diagrams. As such, customers need to sign off on those use cases during PDR. If you let customers continue to monkey with use cases after this review, you increase the risk of “feature creep,” and you’re also likely to run into problems with trying to do a design while the requirements are changing underfoot.

A reviewer of a robustness diagram should be able to read a course of action in the use case text, trace his or her finger along the associations on the diagram, and see a clear match between text and picture. If the reviewer can’t do this, you need to rewrite your use case text, redo your diagram, or both. You should not proceed with a sequence diagram for the given use case without passing this simple test because your use case isn’t done if it doesn’t pass, and therefore, you’re not going to be able to do good detailed design for it. We’re fond of calling this process disambiguation. This involves removing the ambiguity from your use case text. We’d all rather not design against ambiguous requirements if we can avoid it.

One of the reasons to do robustness analysis is to accelerate the evolution of the initial (problem space) domain model toward a final (solution space) class model. You build that final class model by allocating behavior to all of the objects that come into play within your use cases. You can’t do behavior allocation properly if you don’t have all of your classes represented within your static model before you start drawing sequence diagrams.

You should strive to have a pretty full and rich set of attributes on the classes in your domain model when you’re through with robustness analysis for a given set of use cases. As we mentioned earlier, a number of these attributes should match up with elements of your boundary objects, such as fields on a window or screen. Other attributes will be more relevant to functionality that’s internal to the system. If you don’t capture these attributes before you start doing sequence diagrams, your decisions about which class does which operation will be less informed than they should be. When we do OO design, we generally put the functions where the data is. However, within our approach, we make these decisions in two steps: We start allocating data during preliminary design, and we revisit this allocation when we allocate the functions, during detailed design.

As we discussed in Chapter 5, controllers serve as placeholders for functionality and system behavior. You should not start assigning methods to classes on a robustness diagram because you’re not likely to have enough information just yet. You’ll make decisions about behavior allocation using sequence diagrams, as we describe in Chapter 7.

We tell you in Chapter 7 that you should copy the use case text onto the sequence diagram you’ll be drawing for that use case. The result of this is that when you’re doing the design, the required system behavior is always staring you in the face. This reinforces, to the designers, the nature of use cases as contracts between customers and developers. It’s during PDR that you have to reinforce that principle to your customers.

We talked about the concept of premature patternization in Chapter 2. This is also a trap that people tend to fall into during robustness analysis and PDR. It’s healthy to discover patterns across robustness diagrams, especially those that map easily to established design patterns or patterns that you’ve invented. What’s not healthy is expanding simple preliminary design patterns that appear on robustness diagrams into detailed design patterns. Save the latter for sequence diagrams and design-level class diagrams.

On a sequence diagram, it’s perfectly acceptable for nouns to talk to other nouns—this is because the verbs represent the messages between objects—so boundary objects can talk to other boundaries, entity objects to other entities, boundaries to entities. On a robustness diagram, though, nouns only talk to verbs, not other nouns. The associated rules are in place to help you ensure that your use case is expressed correctly, in noun-verb-noun format just like standard English dictates, because we need to have both the nouns and the verbs identified before we draw our sequence diagrams. Consistency of your use case text across the project helps ensure a fairly straightforward move into sequence diagramming as you continue to use your use cases to drive your design.

We’ve already told you that you shouldn’t see methods or design patterns on your diagrams, so you shouldn’t be surprised that we’re going to tell you that you should not be exploring any other facets of detailed design when you’re doing PDR. Also, use cases, class diagrams, and sequence diagrams are persistent; robustness diagrams aren’t (at least, not necessarily; a lot of folks like to keep them around, especially if they’re contained within a visual model, and there’s nothing wrong with this). So, you shouldn’t waste time trying to perfect your robustness diagrams as your design evolves.

Robustness analysis is meant to be a “quick and dirty” technique that helps you tighten up your use cases, discover new objects, and get a good start toward detailed design. Robustness diagrams are meant as a means to an end; it’s a waste of time to make the effort to get the arrows exactly right. You should focus your efforts on perfecting your sequence diagrams rather than tinkering with robustness diagrams.