第三，简单有效才是最重要的。一般说来，项目组成员的设计分析能力、以及对UML的理解使用能力是层次不一的，即使通过培训能提高部分程序员的水平，但是，经验、阅历这是不能通过培训来解决的。因此，只有保持最简单有效的过程，使用最简单的UML图形，才能使得UML的应用达到最佳的效果。而如果我们为了详尽的描述一个用例，使用了一系列完整的时序图、协作图、状态图、部署图、用例图和类图，这样，可能导致一个团队完全脱离面向对象分析和设计。
第四，抉择画图。画UML图是一种非常有用的活动，它也可能成为一种浪费时间的、可怕的活动。不需要制定什么都必须画图的规则，因为这样的规则将比不用更糟糕。项目的大量时间和精力将会被浪费在追逐那个根本没有人去读的图上。下面列举了需要画图的情况：
当许多人一起需要同时进行开发时，这些人需要都理解一个系统的特定部分的设计结构时，开始画图。当所有的人都已经声明理解了的时候，结束画图。
当两个人或更多人不同意一个特定的元素如何设计的时候，需要团队意见一致的时候，要找一个时间进行讨论做出决定，比如投票，或一个公正的宣告的方式进行，这时需要画图。当决定做出来后，擦掉这些图。
当需要探讨一个设计的想法时，画图能够帮我们更好地思考。当得到了能够帮助我们完成思考的代码的要点的时候，扔掉这些图。
当需要向其他人或自己解释一部分代码的结构的时候，可以画图。当觉得其实最好看代码来进行解释的时候，停止画图。
当项目快要结束，顾客需要我们将图与其他文档一起提供的时候，开始画图。
在项目中使用UML，需要时刻记住的是保持简单，并且结合软件工程文档，同时让项目组对过程有统一的认识。很多成功的项目都采用用例驱动，迭代，递增方法的。如果能把过程细化并且让项目组掌握技巧，那么UML项目已经离成功不远了。
系统开发过程
UML简介
UML起源于面向对象的分析与设计方法。
在80年代末至90年代中，对面向对象分析与设计方法的研究发展到一个高潮。但是，诸多流派在思想和术语上有很多不同的提法，在术语、概念上的运用也各不相同，需要一种统一的符号来描述面向对象的分析和设计活动。UML应运而生。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且有进一步的发展，最终成为大众所共同接受的标准建模语言。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术。不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发全过程。
