Summary - Practices

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:

• Do What Works
  
  The first rule is self-explanatory. There’s no point rigidly 
  obeying the rules if your model fails to communicate itself to 
  others, so do whatever works for you in your particular 
  situation.
  
• The Model Rule
  
  UML diagrams are like a user interface into your underlying   model. Different diagrams illustrate different aspects of the  model, and so they will contain different information, but the   complete set should present a coherent picture. Completeness   lies in the model, not in a single diagram.

     •  Legible Does Not Mean Pretty

Don’t spend an age getting your diagrams perfect: they only 
need to look good enough to get across the information that 
they are designed to communicate.

• The MTB Rule (MTB—Minimum Two Brains)

 When you’re working on a new model or idea, always get 
 another member of the team to look at it. They might spot 
 flaws in a model that you didn’t, or help you to correct a 
 diagram. Two or more brains can spark a creative process.

•  The 7 ± 2 Rule

  The average human brain can only hold 7 ± 2 things in its 
  short-term memory, so cluttered diagrams lead to confusion.
  Simplifying diagrams and reducing the number of elements
  often improves communication. When circumstances demand
  complexity, grouping related elembirtents can aid
  understanding.

•  The Résumé Rule

        Each diagram should fit onto one standard-sized sheet of paper.

•  "You just Don't Get It!" Is Never an Excuse

It’s your responsibility to ensure information is communicated. When there’s a problem, listen to the other people, and find out what they understand and where they think the problem lies. Make sure they can communicate the idea back to you.

    •   Every Picture Tells a Story

Every diagram should tell a story in its own right. All the details on that diagram should contribute to that particular story.

• The Highway Map Rule

        Your models are maps to your code, so maintain them alongside
        your code, even after it has built. Although they might become
        a little out of step at times, don’t throw them away.

     •   Define Your Own UML with Stereotypes

         UML doesn’t contain a symbol for everything that you need.
         Sometimes it’s helpful to define your own symbols or add extra
         information to elements using UML stereotypes, but always
         check first that there’s not already something defined that you
         can use, or commonly, conventionally used stereotypes.

     •   Just Enough Modeling: Analysis, Not Paralysis

         Your model will never be completely perfect, and sooner or later
         you need to start coding. Learn to recognize when you have
         created a “good enough” model. Holes and other problems will
         show themselves up in review.

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)