|
|
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 critical design review for their projects. Our "Top 10" list follows.
Invite nontechnical customers to the design review.
Sequence diagrams are generally full of details that most likely won't mean much to any but the most technically aware customers. They exist to be used by designers and developers. Thus, CDR sessions should include those people involved in detailed design and development decisions, and no one else.
Don't check the use case text carefully against the body of the sequence diagram.
A reviewer should be able to see easily the visual trace between a sentence of use case text and a message, or set of messages, that describe that behavior in terms of object interactions. The right-hand side of the diagram should also account for all of the use case's alternate courses of action in ways that are clear to the reader. If this doesn't hold true, it's possible that the designer who did the diagram hasn't fully addressed the requirements expressed by the given use case.
Don't check the origin and destination of every message arrow on every sequence diagram carefully.
It's essential that a sequence diagram show which object is in control at all times. If there are discontinuities, there will be problems with the code if someone tries to build it based on the diagram.
Don't think through the Halbert/O'Brien criteria as you review your sequence diagrams.
You should look for a high degree of reusability of objects across your sequence diagrams, and a high level of applicability of methods within each object. You should also look to keep the complexity level, and the level of implementation specificity, low within methods and within objects as a whole. Working to meet these quality criteria will give you a healthy foundation for a robust object-oriented design.
Don't review your static models for "quality class" criteria.
One of the best sources of guidance for making good behavior allocation decisions is responsibility-driven design. As we explained in Chapter 7, a class should have a single "personality," and you should avoid "schizophrenic" objects. This means that a class should be focused on a strongly related set of behaviors that have minimal dependencies on other classes. The most important of the "quality class" criteria presented earlier in this chapter are high cohesion and loose coupling; single-personality classes are essential to achieving these goals. To expand on this, let's turn to Rebecca Wirfs-Brock (Designing Object-Oriented Software, Prentice Hall, 1990): "Responsibilities are meant to convey a sense of the purpose of an object and its place in the system. The responsibilities of an object are all the services it provides for all the contracts it supports. When we assign responsibilities to a class we are stating that each and every instance of that class will have those responsibilities, whether there is just one instance or many." Make sure, if at all possible, that somebody who's read the Wirfs-Brock book-and understood it-participates in your critical design review.
Don't worry about the "plumbing"; it will take care of itself.
The sequence diagrams serve as the last stop before coding and as such need to show the real design in full detail. This includes details about persistent storage (to which database tables are you going to map the various objects?) and distribution (on which layer or tier will each object reside?).
Don't consider whether design patterns would be of any use in your design.
Design patterns can provide you with a great deal of leverage with regard to the reusability and maintainability of your design. The more patterns you discover and reuse across your sequence diagrams, the greater the momentum you can build as you push toward code, and the more time you'll have to focus on the hard decisions that don't lend themselves to patternizing.
Show "generic" sequence diagrams that disregard implementation technology such as DCOM or EJBs.
As we said earlier in this chapter, sequence diagrams are the last step before code within the ICONIX process. You should be working to minimize the size of the gap that you have to cross between detailed design and implementation by adding a reasonable amount of detail about the technology you're using to build the system.
Don't review sequence diagrams for every scenario that will be built in the current release.
If you don't have, or don't go through, sequence diagrams for one or more of your use cases, or if any of your diagrams don't show both the basic course and all alternate courses for the given use case, there's a good chance that you will miss some behavior that one or more objects needs to perform, make some decisions about behavior allocation that aren't optimal, or both.
Don't worry about the details of your design before you jump into code. Just assume that refactoring the code will fix everything.
Refactoring is defined, in Martin Fowler's book Refactoring (Addison-Wesley, 2000) as "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." This sounds like an excellent technique for optimizing code. However, XPers also rely heavily on the likes of this, from Extreme Programming Installed (Ron Jeffries, Ann Anderson, and Chet Hendrickson; Addison-Wesley, 2001): "[W]hen the design wants to change, as it will, change it." People who discover-and change-the design while they're coding are probably not going to build systems as robust as those built by people who spend a sufficient amount of time completing, and reviewing, the design before coding begins, because you lose the global view of the design when you're focused on coding one small piece of it. Refactoring won't guarantee that everything comes out right if you've merrily skipped past analysis and design-and it certainly won't guarantee that you're building the right system (that is, the one that meets your users' requirements).
Trying to design and code at the same time is like playing chess on the Internet while you're doing your calculus homework. You might be thinking, "Wow, I must be really smart to be able to do this!" to yourself, but if you're like most people, both your chess rating and your math grade would probably improve if you undertook these two mentally demanding tasks separately. (We used to know a guy who wore a T-shirt that said "The clever programmer out-smarts himself again.")
Both design and coding (and for that matter, analysis) are skills in their own right, and there are numerous aspects that must be kept track of at each phase of development. We're about at the end of the book, so we'd like to leave you with this final thought: All humans are fallible, and one of the best ways to reduce error rates is to focus on one thing at a time. "One thing at a time" is one of the central themes that's woven through the ICONIX Process. Even if you take nothing else from this book, we think you'll be more successful if you try to at least keep that simple fact in mind.
|
|