Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说《产品经理业务设计与 UML 建模》：从UML里借鉴可视化思维,希望能够帮助你!!!。

越是在这个变化不确定的世界，越有必要静心思考，夯实认知，好好沉淀自己。

你好，我是「爱思考的大熊」。

今日认知读书系列主题-「可视化思维」。

今天解读的书，是《“图解”产品：产品经理业务设计与 UML 建模》。

UML (Unified Modeling Language)为面向对象软件设计提供统一的、标准的、可视化的建模语言。

只所以解读这本书，是因为UML，作为一种影响力很大的、共识的可视化描述语言，背后关于可视化，一定有值得学习借鉴的地方。

软件领域，往往是能把思维变成工具、可实操方法论的好地方。

所以，我将目光，转向UML。

他山之石，可以攻玉。

希望通过不同领域的知识借鉴涉猎，丰富和加深对于可视化思维的认知。

下面，我把这本书的精华内容，重新整理分享。

本书，有意思的启发，主要有3个。

第一个，UML，是为了提升解决复杂问题的规划和沟通协作效率而生

为什么会有UML？

书里在讲UML的产生历史，是这么说的：

在20世纪80年代之前，并没有UML。那个时候软件设计虽然难，但代码不多，研发人员只需要直接编码即可。在20世纪80年代之后，软件越来复杂，直接编码就会出问题，常常会丢三落四。大家发现只有在编码前做好准备，才能避免问题的产生。这个准备就是要先设计并描述软件架构，于是很多人提出了图形化的描述方法。

其中，做出卓越贡献的三位大师分别是Grady Brooch、James Rumbaugh和Ivar Jacobson，他们也被称为UML三友。他们各自提出了表达方法，这些方法是类似的或互补的。于是三位大师决定将这些方法统一起来，并在1995年推出了UML。

创建UML的三位大师曾先后进入Rational公司工作，并在Rational公司推出了UML的初版。在这之后，由Rational公司发起，各大公司参与的OMG（Object Management Group，对象管理组）被建立起来。当然，该组织的核心成员仍然是UML的三位发明人。建立OMG的目的，是完善UML的标准，促进UML的使用。这个组织的成员包括众多知名公司，如IBM、Microsoft、Oracle等行业巨头。从那以后，在OMG的主持下，UML相继推出了从UML 1.0到UML 2.5等一系列的版本。修订后的UML 2.5版本，还被提交到ISO并被采纳，因此，UML就成了国际标准。后来Rational公司被IBM收购，其产品线也成为当时IBM五大产品线中的一条。

从这段历史描述，我们可以总结出以下3点：

1、简单问题直接上（编码），不需费劲搞个标准，反而麻烦；但复杂问题，涉及广泛协作和沟通，直接上就很低效。需要提前有系统的、清晰的规划；

2、描述问题和规划，理论上可以用文字、编码、图形...但有个大脑接收和认知效率的问题。在这点上，图形整体上，是秒杀文字的。所以，会提出图形化的描述方法；

3、如果是小团队沟通，描述标不标准影响不大。但像软件开发这种覆盖极广，涉及领域和角色极大的工种，没共识标准就是灾难。这也是UML的U(Unified)的来源，标准要统一共识，就跟语言一样，大家都说同样的语言，互相才听的懂，看得懂，否则无法协作提效。

第二个，UML的关键，是有效合理、清晰抽象、分类定义场景和问题。

UML里，常用的有用例图、状态图和类图等。

但关键的，不是着急怎么做图，而是先要把图背后的，对于事情的拆解、归类做好。

把事情想清楚，清晰定义分类的工作做完，再画图就是技术细节。

比如用例图，

用例（Use Case）也被称为用况；

是对参与者发起的一组动作的描述，系统响应该组动作，并产生可观察到的显著结果；

比如，用户在银行办理贷款，这其中，用例就是办理贷款，参与者就是用户，系统就是银行系统，而显著结果是办理贷款成功或失败。该用例是由用户发起的，且该用户在系统上做了一系列动作，这一系列动作概括出来就是办理贷款。

图本身，看看就好，关键是图背后的思路。

简单来讲，用例其实就说一件事：用户在系统上做了什么。

看起来简单，但你往下拆解会发现，这里面有许多子概念：

1、参与者（用户）

2、系统

3、任务（做什么事）

4、动作（怎么做，动词+宾语）

而任务这个概念又能拆成，目的>目标>执行步骤ABC，这些是属于不同类型和层面的事情，也需要做合理有效区隔、分类和分层，才不会混乱。

这时，就又会涉及到

5、用例层级

6、用例关系

因此，有了用例层级图（如下示例）

再比如，状态图

也被称为状态机图，描述了一个对象所处的状态，以及用什么操作可促成状态的转变。

举例，在你按下微波炉的“开始”按钮后，微波炉就处于已开启状态；在你按下微波炉的“停止”按钮后，微波炉就处于已停止状态。在这个案例中，微波炉有两种状态，分别是已开启状态和已停止状态。

或者，在用户下了一个订单之后，这个订单就会被创建。此时，订单处于已下单状态；在用户支付了订单之后，订单变成已支付状态；在运营人员发货之后，订单变成已发货状态。以此类推，订单还有其他状态。

状态这个词，就是“表现出的样子”。

但往下拆解和区分，你会发现，也有一些子概念和组成：

1、开始：定义了一件事情的起始边界

2、状态：当前处于什么样子（etc.微波炉“开启”；订单“已支付”）

3、转移：事情可能从一个样子，变成另一个样子（etc.订单从“下单”，变为“已支付”）

4、内部转移：事情还是在一个样子，但又重复一遍（etc.用户发现下单下错了，又下一遍）

5、结束：定义了一件事情的结束边界

这些子概念和组成，也需要合理有效区隔、分类和分层。

所以，状态图有五种表达方式，分别是状态和转移、开始和结束、内部转移。

再比如，类图

类（Class）是对一组具有相同属性、操作和关系的对象的描述。

结构良好的类具有清晰的边界和关系。

比如，犬科是一个类，该类的属性有姓名、品种、年龄等，该类的状态有健康状态、生病状态等，该类的行为有吃、叫等行为。其实，只要把相似的东西归在一起，就可以称为一个类。

如果把人和狗放在一起，就可称为哺乳动物类。其相似的地方是胎生哺乳、体温恒温等。最后，概括一下类和对象的关系。

类是对具有共性的一组对象的描述，对象是类的一个实际例子。

同理，如果你仔细琢磨“类”这个概念和定义，也能发现，有一些子概念：

1、类和它的属性（类型、具体值）

2、类与类之间的关系类型（比如，一个用户可以下单，用户这个类和订单这个类就有关联关系）

3、类与类之间的关系的量化，可以1对1或1对多（比如，一个人可以养多条狗，人这个类和狗这个类就有数量关系）

当把“类”这个概念琢磨清楚明白，拆解区分，就能理解类图为什么这样画，有什么道理。

第三个，UML有许多规则，了解一些常用的就行。不用死记，关键在领会背后的思想实质。

UML非常复杂，其文档已经达到了近千页之多，共14种图。

也常被诟病太复杂，根本记不住 。

以下是UML图的汇总

其实，对UML的态度，我觉得就和对单词字典一样。

关键是理解背后思想，了解一些常用的（etc.用例图、流程图、状态图和类图），然后大部分就当作工具资料，能用到时查一查就好。

思考清单 - 【可视化思维-UML的启示】

1. 如果你面对复杂问题和大规模沟通协作，可以看看UML是怎么提升认知和协作效率的；
2. UML的关键不在图形。而在思想实质：有效合理、清晰抽象、分类定义场景和问题；
3. UML有许多规则，了解一些常用的就行；关键在领会背后的思想实质。

我是「爱思考的大熊」，喜欢琢磨认知和思考的话题，也在不断实践。关注我，我会持续分享认知和思考方面的内容。如果喜欢我的内容，请长按点赞收藏关注我，后面我会持续分享认知思考方面的思考干货，我们下一篇文章见。

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。