In this chapter, I’ve given you a set of practical “golden rules” to some of the issues that you’ll be dealing with as you begin to analyze your problem domain and develop your model. These are summarized here:
• Legible Does Not Mean Pretty
Each diagram should fit onto one standard-sized sheet of paper.
• Every Picture Tells a Story
Your models are maps to your code, so maintain them alongside
• Define Your Own UML with Stereotypes
UML doesn’t contain a symbol for everything that you need.
• Just Enough Modeling: Analysis, Not Paralysis
Your model will never be completely perfect, and sooner or later
We’re going to come back to the process of analysis and design again in Chapter 5, when we look at gathering and analyzing requirements, but because I want to focus on how you can apply modeling and UML in a .NET environment, let’s take some time out first to see what .NET itself looks like as a UML model. That’s going to be the focus of the next chapter.
1. Scott W. Ambler,Agile Modeling: Effective Practices for eXtreme
Programming and the Unified Process (John Wiley & Sons, 2002)
2. Jeff Del Papa, and The New England Rubbish Deconstruction
nerds.org/contestant-advice.html). Along with The MTB
Rule, this site has some great practical rules for software
development and management: “KISS. Keep It Simple, Stupid.”
“Just remember:If brute force doesn’t work, you aren’t using
enough.” “If you break, you lose.” “MCF: Mission Critical First.”
“Test Early, Test Often.” “Leave margins.” “Identify your hidden
assumptions.” “The machine shop should be a last resort.” “Make
time for silliness.” “If something isn’t right—LET THE DIRECTOR
KNOW RIGHT AWAY!!!” These rules are stated in the context of a
high-pressure hardware effort; but the spirit of these rules applies
to software as well.
3. Stephen King,On Writing (Pocket Books, 2002), p. 103. King goes
on to demonstrate what he means by writing as telepathy; and he
makes a compelling (if metaphorical) case.
4. George A. Miller, Ph.D., “The Magical Number Seven, Plus or Minus
5. Robert A. Heinlein,Stranger in a Strange Land (Ace Books, 1991),
p. 266: “‘Grok’ means to understand so thoroughly that the
observer becomes part of the process being observed—to merge,
to blend, to intermarry, to lose personal identity in group
experience.” In this usage, grokking the whole picture is to see in
it something beyond its individual elements.
6. Jim McCarthy,Dynamics of Software Development: “Don’t Flip the
Bozo Bit” and 53 More Rules for Delivering Great Software on Time
(Microsoft Press, 1995), pp. 30–32. The communication issue is
discussed in depth under “Rule #4: Don’t Flip the Bozo Bit.”
McCarthy’s point in this rule is that assuming that anyone is a
bozo—i.e., they just don’t get it—is destructive for that person
and for the entire team. If they have the skills to make a
contribution to the team, they have a valuable perspective to
bring to any problem; and if you cut off the chance for them to
make that contribution, you might just as well cut them loose from
the team. Never assume your fellow programmers are bozos.
7. Martin Fowler et al.,Refactoring: Improving the Design of Existing
Code (Addison-Wesley, 1999)
8. InAgile Modeling (p. 171), Ambler argues—correctly, I believe—
that they still ended up with a notation that is too large and
bloated for most developers to use completely. Most modelers use
only a fraction of the entire language. A large part of the UML 2.0
effort is to identify the "core” elements of UML.
blog comments powered by Disqus