UML 中各种图形的重要性排行

UML 中包括有很多种图形。我最初学习 UML 是通过三友的《UML 用户指南》，这本书是一本很详尽的著作（另外一本更详尽的著作是三友的《UML 参考手册》），是 UML 领域最重要的著作之一，然而却不利于初学者掌握重点。因为时间有限，我没有能够读完用户指南的全书。对于一个形式主义者，很容易陷入大量 UML 的细节之中，使用昂贵的建模工具（ROSE、Together、PowerDesigner、Visio、etc.）不厌其烦地绘制出各种漂亮的图形，陷入一种分析瘫痪的状态，花费大量时间力图得到完美的模型，却没有生产出多少可以运行的代码。
用户指南中存在的问题正是《UML 精粹》（UML Distilled）这本书存在的价值。我读这本书时感觉非常顺畅（虽然翻译的低劣降低了我的阅读速度，但是好在这本书本身写得非常深入浅出，所以对于我的影响并不是很大），任何一个对于 UML 略有掌握的人读完这本书都不会超过一周时间。搞敏捷开发方法的人（Kent Beck、Martin Fowler、etc.）写的方法论一类的著作都言简意赅，Martin Fowler 这本仅有 100 多页的 UML 入门书籍也不例外。然而不要把这本书仅仅当作一本入门书籍，实际上这本书的内涵要远远超出一本入门书籍。最重要的是这本书将 UML 中各种图形的重要性做了划分，使得我们不必花费数月时间去熟悉 UML 的所有细节，而是只需要看过其中两三章的内容就足以从 UML 中获得巨大的价值。我一向认为那种企图让我一夜暴富赶超 Bill Gates 的书籍是最没有用的书，同样那种企图无所不包却没有重点的方法论书籍也是最没有用的书。

UML 中各种图形重要性的排行为：
用例图（Use Case）
类图（Class）
顺序图（Sequence）
协作图（Collaboration）
包图（Package）
状态图（State）
活动图（Activity）
物理图（Physical）

其中必需的只有用例图和类图。用例图重要是因为它是面向对象分析设计的基础，用例驱动是 RUP、XP 等各种现代开发方法的主要特征（我区分现代和古代的主要依据是看它是否以迭代模型作为其基础，而不是基于瀑布模型，是拥抱变化而不是拒绝变化）。类图重要是因为它是我们用来做分析和设计最主要的工具。

UML 各种图形中内涵最丰富的是类图，然而丰富的内涵也使得对于类图的正确使用遇到了一些困难。Martin 特意将类图的概念分成了两部分：基础部分和高级部分。基础部分是非常简单的，很多时候基础部分已经够用了，仅仅在必需的时候才需要用到高级部分。
这本 UML 的著作大约在 Martin 写完《分析模式》和《重构》之后完成（2000 年第二版），体现了 Martin 在面向对象建模领域的深厚功力。

UML 的价值在于实现开发团队中无歧义的沟通（自然语言本身无法达到无歧义，因此需要 UML 这样的形式化语言的帮助），而不是得到一个完美的图形。这个目的（更好的沟通）是我们永远要记住的，UML 可以很好地服务于这个目的。一旦我们发现已经达到了这种沟通效果，我们就要毫不迟疑地转向代码实现。

用例图的作用其实相当有限，真正有用的是基于文本的用例。
包图的作用不亚于类图的作用，甚至比类图更重要，因为它提供对类的管理指导和说明。

是的，这一点 Cockburn 在《编写有效用例》中已经强调过了。Martin 也说：

所以重要的是用例本身，而不是用例图。对于用例，大多数场合下文本是更有效的表达方式。有的时候还可以适当加一点简单的表格。

包图确实也非常重要，对于组织代码、分层、降低层间的依赖和耦合都非常有效。
另外顺序图也是非常重要的图形。对于划分各个对象的职责、看清楚各个对象之间的协作关系非常有效。在《J2EE 核心模式》一书中我们看到大量顺序图的使用。

UML的图形的重要程度与项目阶段有关。

在项目调研阶段，我觉得顺序图、活动图、状态图比较重要，结合传统的IPO、数据流图、功能角色表等图表，use case我个人觉得其重要性并没有想象的那么大，一般用户还是会按照功能清单方式来做项目的定义，画一堆use case用户也懒得看。画use case，我们的做法是定义功能点，做出清单出来。
顺序图在这些图例里面比较直观，用户能很快参与到讨论中，活动图和传统的流程图类似，也是一个补充，状态图在业务系统调研时往往会被忽视，对关键对象是一定要做状态分析的，经常会在做状态分析的时候发现业务上忽视的问题。类图在调研阶段可以用，但对分析人员要求较高，简单的项目，可能很快就直接可以进入到实质设计工作中了。

在开发阶段，除了类图、状态图外，其它的UML图都不是非常管用，我很反对在开发阶段做大量的UML图例和文档，业务设计人员或者顾问会及时的补充业务设计文档，使用手册和测试用例可能是最关键的两个文档了。

我个人觉得UML的价值不在开发阶段，主要是在业务分析阶段，怎么能尽快的让客户和开发人员理解业务、进行沟通。

UML 还是限于开发团队之内的沟通。和用户做沟通 UML 未必是最有效的沟通手段。robbin 曾经说过他发现使用 UML 来和用户沟通的效果远远不如使用 PowerPoint。PowerPoint 可以嵌入各种生动的图形和表格，还可以支持超链接，是编写需求文档的重要工具。而用例图有一些特殊的表示方法（扩展、包含等等开发人员很容易掌握的概念，用户未必容易掌握），用户很难看懂。用例图的优点是精确，如果需要这种精确性，可以画些用例图。一些建模工具可以自动建立用例图和类图等其它图形之间的联系并且自动维护它们之间的一致性，如果认为这种联系很重要，也可以画用例图。不过从我个人的经验，文本形式的用例还是很有用的，很多时候只需要文本形式的用例就足够了。

作为捕获需求的用例，也有一个小小的缺点。“先画出界面，再写用例就好写多了”这是我听过的有关用例最佳实践的技巧。这说明用例多少涉及了设计的因素在里面，也就是说用例稍稍超出了需求的范畴，限制了一部分的设计思路。

UML图例的价值我觉得还是在业务调研和分析阶段，开发阶段的价值就要弱些。

我举个例子：订单业务的处理，涉及到客户、销售工程师、客户工程师、销售主管、计划工程师、库房管理员、财务、以及生产、材料、储运等各部门，还有企业自己的ERP、生产系统等，比如SAP、QAD等，这种具体业务会非常复杂，在进行业务方交流的时候，用顺序图的效果要远远强于其它的图例，订单在整个流程中的状态也显得非常重要，不同状态下有哪些活动、哪些规则、如何切换，这些都是要和业务方一起来进行讨论的，具体的一些小的业务流程就可以用传统的流程图（往往业务方的体系文件中要求用业务流程图来表示业务过程）、活动图来做细化。
业务方对顺序图的理解很容易，一般不用做太多说明马上就明白，因为涉及到具体的业务部门和角色，动作和传递的消息也很清楚，可以在整体上保证业务理解不产生偏差，具体的细节就要靠其它的方法来补充，比如文字说明、IPO表、对象状态表、业务流程图等，真到开发阶段，业务文档的补充就是一些细节问题了，可以逐步完善，但是变更量会很少。

至于这个顺序图是放在PPT、WORD，还是其它的文件里面就看顾问自己的喜好或者公司的文档标准。

我想Robbin指的是用ppt把各种图表进行整理后和客户做汇报吧，更偏重于一种方案汇报的形式，实际上我们也经常会采用PPT来做方案讲解，里面有大量的图表。

为什么说开发阶段价值没有调研分析阶段大，可能是我们项目的特点决定的，基于企业的管理业务进行开发，项目代码框架基本固定，开发标准只要确定，业务开发的模式化程度就会很高，只要业务理解了就可以，具体怎么去实现用顺序图等图例来描述没有什么意义，类图用的比较多，如果没有类图和代码的同步工具，那么类图我们也只是当作对象关系图来用，具体的属性和方法都去看javadoc。

项目的代码框架、中间服务程序和底层代码，需要用到一些UML图例，不过应该不会很多，架构设计人员会针对一个具体的程序采用部分UML图例进行说明，详细的就要去看代码了。

use case图可能是用的不好吧，我觉得use case不如功能清单好用，至少我所看到的也都是把功能清单转换成use case了，自己内部交流和跟客户交流的时候都觉得费劲，内部为了一个箭头的画法还要讨论半天，跟客户交流的时候要解释图例，最后还是用功能清单皆大欢喜。

我现在用playcase ，感觉比较简单，客户也容易看懂。

    功能清单最大的问题就是关注了细节,而无法从一个更高更加抽象的角度去看待业务以及系统的问题.最应该的方式是首先用用例图建立一种对系统或者对业务的一种功能抽象(这也可以用得上XP中的隐喻的概念),然后再逐步细化为功能清单.
    很多朋友感觉用例图不好,其实只是没有理解或者看着用例图所描述的功能抽象与系统处理业务的抽象. 其实很多画用例图的人都不是一个业务分析专家,use case应该由业务分析员来做,而不是技术方向的系统分析员.