|
|
The flip side of the principles we just discussed takes the form of a number of common errors that we have seen students make when they're doing robustness analysis on their projects for the first time. Our "Top 10" list follows.
Violate one or more of the noun/verb 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 Chapter 7, which focuses 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 actor(s) involved in your use cases.
Don't use robustness analysis to help you use a consistent format for your use case text.
The boundary object-controller-entity object pattern will tend to appear on many of your robustness diagrams. This pattern has a close correlation 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 that you can, which will greatly improve their readability and maintainability.
Don't 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 very 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.
Don't use robustness analysis to ensure consistency between class names on class diagrams and in use case text.
Specifying system usage 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.
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 just yet. You'll make decisions about behavior allocation using sequence diagrams.
Include too few or two many controllers.
We recommend having 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 doesn't really describe enough behavior. On the other hand, if you have more than ten controllers on one diagram, you should consider splitting your use case up into more manageable chunks.
Take too much time trying to perfect robustness diagrams.
The robustness diagram serves as something of a "booster-stage engine" that gets the process of driving use cases forward into an object-oriented design off the ground. Robustness analysis is a tool that 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.
Try to do detailed design on robustness diagrams.
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.
Don't perform a visual trace between the use case text and the robustness diagram.
We strongly recommend that you have peer review of 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 you can pass the simple visual trace test. When you've reached the point where all 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 first-draft, vague, ambiguous, abstract use case text alone.
Don't 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. You can't allocate behavior to classes that don't appear in your static model, after all.
|
|