互联网产品设计进阶（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）状态机的特点是可以有效的降低一个复杂系统的复杂度。很少人能体会到状态机的强大之处，要解释一下状态机为什么会很好的降低问题的复杂度，他对程序架构有和帮助。

?

一个网友的提问：?16:29:54
1. 看了 《UML和模式应用》，书中的例子 pos 机，作者把 “处理销售” 定为一个 系统用例， 这个明显是 主参与者的一个完整业务目标， 但按我过去的理解这个应该是 业务用例才对。 我可否这样理解： UML和模式应用 一书中的所谓系统用例其实就是我所谓的业务用例，都是一个级别的，只是采用的名字不同罢了 ？

? 2. 再说边界，书中边界是以 POS机为系统边界，定义出主角是 收银员 而 不是 购买者， 但是我看的其他书中在需求分析的时候一般是按业务目标来划分边界的。是不是可以理解为边界的定义方式可以有多种呢 ？

?3.? UML和模式应用 一书，里头没有分析模型，而是从领域模型开始直接到设计模型，但是这里运用了所谓的 GRASP 原则为各个对象分配职责。但是一般来说，我们是根据系统用例场景绘制时序图，然后从时序图里为 分析类的3个元素：边界类，控制类，实体类 分配职责的。

?4. 分析模型的意义主要在于严格按软件工程中要求的做需求和实现同步（高于语言实现层次），或者一个项目要卖给不同客户，而不用客户要求的实现语言平台不同，这时候分析模型抽成层次高，可以通用。GRASP 里面的原则也是根据时序图，结合领域模型给对象分配职责，只是它好像是语言级别的，不像分析类那样用文字来表示一个消息。

?? 以上4个问题哪位能解答一下

?

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!