Practices
  Home arrow Practices arrow Page 7 - Introducing UML: Object-Oriented Analysis and Design
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
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? 
Google.com  
PRACTICES

Introducing UML: Object-Oriented Analysis and Design
By: Apress Publishing
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 89
    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:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log 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


    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
     

       

    PRACTICES ARTICLES

    - More Techniques for Finding Things
    - Finding Things
    - Finishing the System`s Outlines
    - The System in So Many Words
    - 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





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 6 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek