迷途书童

by Kendall Scott and Doug Rosenberg

Read part 1: Driving Design with Use Cases 
Read part 2: Driving Design: The Problem Domain
Read part 3: Top Ten Use Case Mistakes

Welcome to the fourth in a series of five articles that provides a pre-publication look at the annotated example from the forthcoming Applied Use Case Driven Object Modeling. (Addison-Wesley, 2001; tentatively scheduled for June). We're following the process detailed in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), as we dissect the design of an Internet bookstore. This article is the third one in which we show common mistakes, and then explain how to correct them.

This article focuses on robustness analysis, which involves analyzing the narrative text of use cases and identifying a first-guess set of objects that will participate in each use case, then classifying these objects into three types:

1. Boundary objects, which actors use in communicating with the system.
2. Entity objects, which are usually objects from the domain model (the subject of "Driving Design: The Problem Domain," Jan. 2001).
3. Control objects (which we usually call controllers because they often aren't real objects), which serve as the "glue" between boundary objects and entity objects.Figure 1 shows the visual icons for these three types of objects.

Within the ICONIX process, this simple but highly useful technique serves as a crucial link between analysis—the what—and design—the how, as shown in Figure 2. Figure 3 shows where robustness analysis resides within the "big picture" for the ICONIX process.

The Key Elements 
Robustness analysis plays several essential roles within the ICONIX process. Note that you will refine both your use case text and your static model as a result of robustness analysis, as shown in Figure 4.

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 is unreasonable—or impossible—given the set of objects you have. 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.

It also provides a completeness and correctness check by helping you determine if the use cases address all necessary alternate courses of action, which we discussed in the third article in this series, "Top Ten Use Case Mistakes" (Feb. 2001). In our experience, the time spent drawing robustness diagrams toward this end, and also toward the end of producing text that adheres to some well-defined guidelines, is invariably made up three- or four-fold in time saved in drawing sequence diagrams.

Robustness analysis enables the ongoing discovery of objects; a crucial step because you almost certainly missed some objects during domain modeling. You can also address object naming discrepancies and conflicts before they cause serious problems. And, robustness analysis helps you ensure that you've identified most of the major domain classes before starting sequence diagrams.

Finally, robustness analysis fills the role of preliminary design, by closing the gap between analysis and detailed design.

Let's take a closer look at the three stereotypes that we apply to objects during robustness analysis.

Boundary objects are the objects with which the actors (for instance, the users) will be interacting in the new system. These frequently include windows, screens, dialogs and menus. If you have a GUI prototype in place, you can see what many of your primary boundary objects will be, and if you follow the guidelines we gave you last month, you can also easily pick boundary objects out of your use case text.

Entity objects often map to the database tables and files that contain the information that needs to "outlive" use case execution. Some of your entity objects are "transient" objects, such as search results, that "die" when the use case ends, and many of your entity objects will come from your domain model.

Control objects (controllers) embody much of the application logic and serve as the connecting tissue between the users and the stored data. This is where you capture frequently changing business rules and policies, and localize changes to these objects without disrupting your user interface or your database schema down the line. Once in a while (perhaps 20 percent of the time), controllers are "real objects" in a design, but controllers usually serve as placeholders to assure that you don't forget any functionality and system behavior required by your use cases.

You perform robustness analysis for a use case by walking through the use case text, one sentence at a time, and drawing the actors, the appropriate boundary, entity objects and controllers, and the connections among the various elements of the diagram. You should be able to fit the basic course and all of the alternate courses on one diagram. Four basic rules apply:

1. Actors can only talk to boundary objects.
2. Boundary objects can only talk to controllers and actors.
3. Entity objects can only talk to controllers.
4. Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors

Keep in mind that both boundary objects and entity objects are nouns, and that controllers are verbs. Nouns can't talk to other nouns, but verbs can talk to either nouns or verbs. Figure 5 summarizes the robustness diagram rules.

Anyone who reviews a robustness diagram should be able to read a course of action in the use case text, trace his finger along the associations on the diagram, and see a clear match between text and picture. You will probably have to rewrite your use case text as you do this, to remove ambiguity and to explicitly reference boundary objects and entity objects. Most people don't write perfect use case text in the first draft.

In addition to using the results of robustness analysis to tighten up the use case text, you should also continuously refine your static model. The new objects you discover drawing the diagrams should become part of your class diagrams when you discover them, and this is also the right time to add some key attributes to your more significant classes.

Top 10 Robustness Analysis Errors
Many of the students we've taught make a number of errors when they're doing robustness analysis for the first time. Our "top 10" list of solutions to common errors follows.

10. Don't violate the robustness diagram rules. These rules are in place primarily to get your text into noun-verb-noun format and to help ensure that you don't start allocating behavior to objects before you have enough information to make good design decisions. (We'll talk more about behavior allocation in our upcoming article on sequence diagrams.) The rules about boundary objects are in place to ensure that you explicitly specify the boundaries of the system, outside of which reside the actors involved in your use cases.

9. Use robustness analysis to help you use a consistent format for your use case text. The boundary object-controller-entity object pattern tends to appear on lots of robustness diagrams. This pattern closely correlates with the subject-verb-object pattern of basic English sentences. You should use robustness analysis to make the text of your use cases stylistically consistent among themselves to the largest extent you can, which greatly improves their readability and maintainability.

8. Include alternate courses on robustness diagrams. You need to perform robustness analysis on all of your use case text, not just the basic courses. Much of the interesting behavior of a system occurs in the context of alternate courses, so it's important to analyze that behavior as part of your modeling efforts. Robustness analysis can also help you discover new alternate courses, especially when you draw controllers with labels such as Verify and Validate.

7. Use robustness analysis to ensure consistency between class names on class diagrams and in use case text. Specifying use case text in the context of the object model is the magic formula you need to build useful sequence diagrams. By naming your boundary objects and entity objects in your use cases, you take a healthy step toward getting your sequence diagrams off to a good start, by simply drawing those objects across the top of the sequence diagram for each use case.

6. Don't allocate behavior to classes on your robustness diagrams. As we mentioned earlier, 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. Make decisions about behavior allocation using sequence diagrams.

5. Don't include too few or too many controllers. We like to see between two and five controllers on a robustness diagram. If you only have one controller per use case, you're likely to have a lot of very small use cases, each of which don't really describe enough behavior. On the other hand, if you have more than 10 controllers on one diagram, you should consider splitting your use case up into more manageable chunks.

4. Don't take too much time trying to perfect robustness diagrams. The robustness diagram serves as a "booster-stage engine" that gets the process of driving use cases forward into an object-oriented design off the ground. Robustness analysis helps us discover objects, allocate attributes, and check the use case text for completeness and correctness. But once we've accomplished the overall mission, we don't need to maintain the work product. It's a means to an end, not an end in itself.

3. Don't try to do detailed design on robustness diagrams. The concept of throwaway diagrams is useful in connection with preliminary design; it's 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.

2. Perform a visual trace between the use case text and the robustness diagram. We strongly recommend that you have a peer review for all of your use case text and robustness diagrams, with each reviewer performing the finger trace technique that we described earlier. You should not consider your use case done until it passes the simple visual trace test. When you've reached the point where each of your use cases pass the test, the next step-drawing sequence diagrams-will be easier for you to perform than if you were starting from your use case text alone.

1. Update your static model. You must update your domain model before you can consider yourself done with robustness analysis and ready to move on to interaction modeling using sequence diagrams. After all, you can't allocate behavior to classes that don't appear in your static model.

Figure 6 shows a robustness diagram that contains violations of four of the top 10 rules.

Did you spot the violations?

• The Home Page boundary object is talking to the Login Page boundary object and the Account Table entity object, violations of rule 10.
• The Account Table object has a method assigned to it. This violates rule six.
• There aren't any alternate courses (what happens if the passwords don't match, for instance?) associated with the Validate Login Info control object, a violation of rule eight.
• The Intercept Request object is a construct that belongs to detailed design. This violates rule three.

Figure 7 shows the robustness diagram with the mistakes corrected.

Our next article will demonstrate how to draw sequence diagrams, which reside at the core of detailed design within the ICONIX process. See you next month.

Note:  denotes analysis paralysis.