更为重要的是，UML可以帮你记录下从设计就开始出现的错误，要知道糟糕的设计会带来一系列的麻烦。设想一下，在源代码编制到一半的时候，你忽然发现你所需要的信息已经枯竭了，但你却没有办法重新取得信息，因为你没有引用OBject，甚至于你引用了object，然而信息确是非public的。显然的，你将花费数天时间来找出代码的变化。
UML可以帮您摆脱如下一些困境：代码随着细节的增多而累积，因此，查找哪些是系统的基本要素，了解objects之间的关系如何以及它们之间怎么联系都会变得困难起来。当大量的代码产生出来的时候，做一些改变也变得困难。因此决定一个对象的功能被分配到协作中的设置是一项主要的工作。甚至有时只是改变一个方法的名称那样简单事情，也很可能导致一个很长的编辑----编译---错误循环。
在编码之前高水平的设计是进行正确的需求分析和精确的定义，UML的自动化工具固然重要，但UML在设计讨论中就显得更为有用。
OOA, OOD, and OOP
什么是OO分析和设计？它们与OO编程相比又有什么不同之处？要了解这些，请注重观察一个程序的循环过程
第一步，需求收集：首先要规划好系统，计划好系统的实施步骤。通常人们都会通过讨论来萃取出需求，并做具体记录，然后与要害用户或是消费者一起探讨并使他们同意你们已把握系统正在解决的问题。
OOA （Object oriented analysis）即是描述系统实施与系统规划相结合一个的进程。解析放大了处于问题中心区域的目标，分析它们的重要作用是什么，分析何种目标与何种目标相联系。另外，解析还决定何种目标从属于公用类别。
非凡地是，解析应与现实生活中的问题类似，不需要产生什么新的复杂的问题。你甚至可以与一个不懂技术但懂得这些问题的人员来分享这些解析，他们可以指出你在解析中遗漏了什么，忽略了什么或者哪些地方出错了。
OOD 在设计阶段，你得预备将具体问题放大化以便分析。然后你得决定方法的自变量有哪些，以及它们的return类型。你也许可以发现新类将会帮您完成设计 。你可以抽象出公用的功能到接口或基类中。一个单一的分析类可以分解成为几个合作类。总而言之，你仍停留在规划阶段，而不是实施阶段。。
OOP在您搭建好一个框架后，下一步就是实施代码了。在合适的设计后，你可以按以下步骤来实施细节：
1、是使用哈西表或者是二叉树
2、是使用RMI还是CORBA来完成客户/服务器的通信？
3、用何种语言？
为了更真实的体验到UML是怎样在解析及设计阶段起铺助作用，则需要通过解决一个问题来了解。
一旦你将一切都代码化并且处于施行中，你就可以将周而复始的循环运用。随着系统交付日期的临近，更会发现什么地方不足，以及下一步需要完善哪一部份。通过使用交互式的解析、设计，完善及运行，你可以很迅速、稳定地重复运行及完善系统，而不需要担心遗失代码。？XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/bianchengyuyan/）
