|
|
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.
Don't make sure the customers know that this is their last chance to change the behavior before this release of the system is built.
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.
Don't make sure the use case text and robustness diagrams match.
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.
Don't make sure that new entity objects are added to the domain model.
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.
Don't look for attributes on the domain classes.
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.
Expect operations to be allocated to classes during PDR.
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.
Don't advise your customers (again) that use case text is a contract between developers and clients.
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.
Require the preliminary static design to make extensive use of design patterns.
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.
Don't review the noun/verb rules of robustness analysis.
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.
Expect your robustness diagrams to show a complete detailed design rather than a conceptual 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.
Review the direction of every arrow on a robustness diagram carefully instead of doing a quick trace to verify you've accounted for all of the behavior.
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.
|
|