互联网产品设计进阶（7）还需要懂点UML

UML是一扇窗，打开了它，你就能看见更多东西。

当你感叹UML是集计算机专家思想大成之作时，你肯定体会到了这些图的精妙之处。

首先来联想几个常见的场景。

北京奥运会，中国长卷气势恢宏，精彩场景万众瞩目。从张艺谋到控制烟花的操作手，每一个环节都不容差错，如何快速沟通？

年末贺岁大片大战，从《阿凡达》、《十月围城》到《让子弹飞》，片场情节纷繁复杂，每一个环节都会体现不同的设计思想。如何选择一个合适的方式，让演员和片场工作人员都充分领会导演的意图？

在 让子弹飞的同时，也让思路回归到软件设计。在这个设计过程中，用户会提出复杂的需求，每次的每个业务都可能不一样。而程序员则有自己所擅长的技术，轻松套 用一个框架当然最好了。可是，最后很容易出现程序所表达的核心功能和客户的核心业务不一致，很多软件作坊也在不知不觉中走进了修修补补的误区。

1 ．UML有多大的价值？

到底谁服从谁呢？毫无疑问，我们要尊重客户的需求。

对 于程序员而言，框架、技术、设计技巧是死的，分析业务是最难的。如果没有好的方法学去分析业务，那么，设计出来的模型肯定不太能客观反应现实。然后，即使 有再好的框架、技术、分层架构、ORM、缓存，都没用了。由此，我们会引申出一个话题：怎么选择一种最合适的表达方式，让大家的沟通更顺畅？

或许有人会说，我觉得大部分UML不需要使用工具画出来。很多时候用白板画一下，大家都理解了，然后就可以擦掉了。

或许还有人说，我们公司做电子商务的，我们一般用到状态图，其他的不怎么用到。

再或者，其实很多公司是为了写UML文档而写UML，UML的作用到底有多大，很多人都持怀疑态度？难道，大家就只是迷恋工具，因为别人UML，所以我也UML？由此认为，一个工具就能搞定所有的疑惑。

这就是撰写本书的初衷，我们需要重新解读UML。也许，需求与UML没有直接关系，但是UML可以专业的表述需求。细细品读一下，为了能够更清新的把握务求，UML其实发挥着十分重要的作用。比如，沟通、记录、启发、存档；理解客户需求，最终形成开发文档。

每 个人对需求的理解方式都不一样。归纳起来，UML只是把大家的理解统一了一种表达形式，有助于相互之间的沟通，便于团队成员之间传递一致的需求，从而达到 需求概念的一致性：需求分析人员使用UML模型与客户沟通，直接明了，同时通过UML模型传递客户需求给设计人员；设计人员使用UML模型描述客户需求， 传递给开发人员；开发人员使用统一的概念和语义理解UML模型，最终使团队各个角色在需求上达到一致的理解。

2 ．解决学习UML的困惑

在日常交流中，我们发现，很多程序员有这样的第一感觉：看不懂UML。或者，很多程序员做UML的时候，明明脑子里有一个路线图，可是不知道该用什么图来表达自己的设计意图。还有人会直截了当的提出：有必要把整个系统用UML表达出来吗？

当然，许多项目经理也有自己的困惑。比如，明明自己心里很清楚，可是，当他面对一个新人的时候，却不知道怎么解释系统模型、流程。无形之中，形成了一种交流上的沟壑。

当 我们讨论这些话题的时候，很自然的会延伸到许多概念。比如，模型驱动设计，领域驱动设计。概念越来越多，而我们的脑袋却越来越晕。试想，项目一旦复杂后 UML类图就会复杂化，让人看不懂。一个大型项目里面的类和关系都会很复杂，UML类图会膨胀，有的时候程序需要改动了，UML也要及时更新了。于是，有 人又提出了类似领域边界的概念。如此反复，更多的人也许就会被弄晕了！

其实，UML很简单，就是不要把UML当回事。我们可以尝试以下思路：

l 画UML就像做数学题打草稿，是帮助我们尝试观点，弄清题意的。

l 在表述UML结构时，先从大的概念上进行模块划分，然后再从局部详细处理。

l 把注意力集中到业务上来。这就是说，我们要解决的是问题，但大家总是把注意力集中到解决问题的工具上。当问题被解决后，大家心里有数了，进而可以告之，换个工具可能更好，有什么优点。

在 这样的思路指引下，如果把问题分析清楚，用文字描述也好，用图描述也罢，问题是清楚的。师傅教时，老师教时，课本上讲时，肯定更多的集中在工具如何使用 上，如何用工具来解决问题。当我们达到一个运用自如的境界后，这时我们需要关注的是，我如何如这个工具来解决类似的问题。

按照这个思路，进而去讨论UML，那就是十三种图，常用的几种与不常用的几种，知道各怎么用，表达什么意思也就游刃有余了。

3. UML 中常用的视图

UML 是Unified Modeling Language（统一建模语言）的简称，如果给其一个权威的定义的话，Booche在其经典著作《The Unified Modeling Language User Guide》中这样描述：UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言。此处的制品主要是指软件开发过程中各个阶段的产物，比 如需求用例、源代码、测试用例等。

UML建模机制可以分为静态建模机制和动态建模机制，静态建模机制所建立的模型都是静态的,包括用例 图、类图(包含包)、对象图、组件图和配置图等五个图形；动态建模机制所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活 动图、顺序图和协作图等四个图形。那建立这些图能够起到什么作用，达到什么目的呢？

l 使用模型可以更容易理解问题

l 使用模型可以更好地加强人员之间的沟通

l 使用模型可以更早地发现和纠正错误，甚至规避错误

l 使用模型可以得到需求结果和设计结果

l 使用模型可以使团队新成员更快地融入项目中

l 使用模型可以为源代码留下原型

4.补充一点

UML 本身是个整体，尤其要明白，为什么要有这些图，为什么不是其他图，这些图就够了吗？时序图缺少了哪些信息？而状态机缺少了哪些信息？为什么这些图有机结合 在一起就能很好的刻画一个系统。例如状态机视图是可以有一个完全严格的实现的，相对严格，而时序图则不行。来自一位熟悉的朋友的建议：

（1）状态机的变迁，即最早的状态迁移图，mealy装调剂，more状态机，以及后来的安全状态机等等。为什么会有这些变迁，以及这些不同状态机的差异，和主要应用领域。尤其是清楚状态机应该应用的什么场合。言外之意，就是什么地方不适合状态机。

（2）UML状态机自身的缺陷，然后用面向对象给出一个状态机模式的实现，分析不同实现方法的优缺点。它本身是和面向对象思想是紧密联系的，对比辨析一下，状态机思想和面向对象思想的差异和联系。

（3）状态机的特点是可以有效的降低一个复杂系统的复杂度。很少人能体会到状态机的强大之处，要解释一下状态机为什么会很好的降低问题的复杂度，他对程序架构有和帮助。