Practices
  Home arrow Practices arrow Page 7 - Introducing UML: Object-Oriented Analy...
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
PRACTICES

Introducing UML: Object-Oriented Analysis and Design
By: Apress Publishing
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 56
    2005-07-21

    Table of Contents:
  • Introducing UML: Object-Oriented Analysis and Design
  • Analysis
  • UML
  • UML Diagrams
  • Component Diagrams
  • Package Diagrams
  • It’s All About Communication
  • Summary

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    PCmover - $15 Off with Coupon Code CJPH7Q

    Introducing UML: Object-Oriented Analysis and Design - It’s All About Communication
    (Page 7 of 8 )

    I hope that the exercises in this chapter have eliminated any mystique about UML in your mind; but even more, I hope that I have set an example of how UML can be used to communicate ideas. The underlying point for this section and the whole book is this: UML is about communication.

    Don’t worry about being perfect all at once (or ever!). If you’re communicating, you’re using UML effectively. There’s always room for improvement; but don’t let imperfection stop you from progress. That’s a key point in learning and applying UML and in applying UML as part of a process. Your designs won’t be perfect; but as your team reviews them and you refine them, they will become good enough: good enough to build the system, good enough to guide the testing and the documentation, good enough to drive the management of the process. A team that waits for perfection is just as bad as a team that is wedded to code-and-fix: neither team produces an effective design that leads to a successful system. Remember: code-and-fix bad; design-and-fix good.


    Letting Go of Perfection: A Lesson from the Graphic Arts

    If I haven’t persuaded you yet to let go of perfection, it won’t surprise me. It’s easy for me to say that you can make imperfect diagrams and improve them later; but how do you do it? How do you just sit down and start drawing diagrams when there’s nothing you know? I hear this most often from students who are drawing Sequence or Activity Diagrams: “How can I draw this diagram until I know which objects are in the system?” And they have it exactly backwards: they’ll use the diagrams to discover objects that solve the problem. But they want to draw the right picture. Maybe they’re afraid to look foolish in reviews. (Reviews can be intimidating even to a strong ego like mine!) Maybe they’re just hypersensitive to the risks in the wrong design. Maybe they have embraced the idea that the design is supposed to help them get things right, and therefore are reluctant to risk getting things wrong. But whatever the reason, they just can’t seem to let go.

    So I try a different approach. My students who have seen me sketch diagrams at the flip chart are very aware that one thing I’m not is an artist. But borrowing a technique from the graphic arts,12 I draw the images shown in Figure 1-10, one on top of another.


    Figure 1-10.
      Refining from imperfect to communication

    The technique is simple: put down some detail—even if it’s wrong, such as the sizing circles in the first image —to serve as a basis for further development; then add and erase detail as needed to refine the picture. I’m still not an artist (I draw fencers because the hard parts are hidden behind a mask and a weapon); but by applying some simple techniques and refining, I end up with a much more recognizable picture than I would have if I sat down and tried to draw a perfect fencer from scratch. Imperfection and refinement produces better (and faster!) results than does a foolish insistence on perfection.

    Scott Adams tells us, “Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.”13 Take this attitude to heart in your analysis and design process.


    More Practices Articles
    More By Apress Publishing


       · real nice and helpful article, Thank You
     

    Buy this book now. This article is excerpted from the book UML Applied: A .Net Perspective, by Martin Shoemaker (Apress, 2004; ISBN: 1590590872). Check it out at your favorite bookstore. Buy this book now.

       

    PRACTICES ARTICLES

    - Basic Data Types and Calculations
    - What`s the Address? Pointers
    - Design with ArgoUML
    - Pragmatic Guidelines: Diagrams That Work
    - Five-Step UML: OOAD for Short Attention Span...
    - Five-Step UML: OOAD for Short Attention Span...
    - Introducing UML: Object-Oriented Analysis an...
    - Class and Object Diagrams
    - Class Relationships
    - Classes
    - Basic Ideas
    - Choosing the Right Team
    - Trees
    - Basic Array Searching in C++
    - Solving Problems with Recursion




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 2 hosted by Hostway