产品篇从UML建模看产品经理必备的“系统思维”

Posted 2021-04-17 穿职业装的熊霸天

一、建模：从混沌到有序

你未看此花时，此花与汝同归于寂；你来看此花时，则此花颜色一时明白起来。——王阳明

如果没有人，宇宙只是一片混沌，是人赋予了宇宙以意义和概念。宇宙本没有花、没有草、没有树…是人类把长得像“树”的东西叫树，把长得像“草”的东西叫草，把长得像“花”的东西叫花。从古希腊神话各种神灵，到如今的科学公式，其本质都是人类认识世界的一种“模型化”方式，也就是建模的思维。譬如针对为什么会下雨的问题，无非以前“建模”成龙王打喷嚏，现在“建模”成云层遇到冷空气…虽然科学和认知在不断进步，但其背后人类本质能力却是不变的，将现实简化、将混沌变为有序的基本认知原理是不变的。

二、面向对象的建模

万事万物皆为“对象”，对象不单纯只是软件代码当中的“对象”而已，从古代开始的象棋、围棋 都是对象的概念，对象建模完美契合于中国古代“局”的哲学思想，做局、布局、入局、出局…“局”的本身就是一个面向对象的系统。“对象”只是“实体”的一个抽象，而对象又可以往上再抽象。例如象棋，在棋盘上兵、马、炮、车 每一个棋子都是实实在在的一个“对象”，而兵、马、炮、车 等又各自是一个“类”。就如同一则古老的哲学争论——“白马非马”，现实中不存在“马”这个实体，我们日常生活中人只能见到“白马”“黑马”“黄马”，“马”只是“白马”、“黑马”、“黄马”的概括。再进一步思考，我们日常生活中其实见到的也并不是“单一的白马”、“单一的黑马”、“单一的黄马”，见到的肯定是“多高多瘦什么颜色”附带各种各样属性的实实在在的“马”，并不存在完全一模一样的马，所以现实中的马，我们眼睛看到的只是马的“实体”。而我们人类语言描述的只是马的“对象”，进而往上抽象成“马”这一个“类”。所以老子才会说“道可道，非常道。名可名，非常名”，用语言描述的“道”，已经不是那个天地贯常运行的“道”，用语言描述的那个事物名称，已经不是那个实实在在的“名”。所以，面向对象建模不是什么高深莫测的知识和学问，而是符合我们人类认知的本能，就如同呼吸一般，平常时未注意但无时不刻我们胸中的膈肌在吸收和排出空气。

三、系统思维及其组成要素

系统主要的构成要素有：边界、粒度、组件、结构（关系）、信息流、作用力、环境、外界对象

边界：系统本来是有机融为一体的，就如同中国古代将“天”、“地”、“人”融为一体来考虑，中国“阴”和“阳”是统一在一起的，是不能分离和单独存在的，“一”就是“二”，“二”就是“一”。但西方的“科学体系”的研究方法，讲究拆解出来单独思考。单独思考一项系统的时候，就要考虑边界的问题，否则无从研究。就好像，人体外、人体内，以皮肤为边界，边界内的是人体整个“生理系统”，所以系统思维的本身，就是一种拆解研究、确定边界、分割成一块一块单独突破研究的思维方式。

粒度：系统是分层级的，系统下面分为不同组件，每个组件内部又蕴含一个系统，不同层级下系统的组件（构件）是不能放在一起讨论的，例如人体是一个大系统，肺是呼吸系统的一个构件，肺泡是肺这个子系统的组成部分，进而肺泡在生理这个大系统中跟皮肤是不在一个层级粒度的，系统思维中要注意这个层级关系。

结构：同为木块，“好的形状+好的结构”能拼凑成故宫这样的宏伟又结实的建筑，结构松散，又组成了容易转动的风车，其区别就在“结构”上。小到桌子椅子，大到国家外交，结构（关系）不顺，则系统势必松散和分崩离析，曾今我一直疑惑，为什么有时候那么多聪明人在一起做事，反而事情做不好，原因就是“结构”使其产生内耗，所以崇祯拯救不了没落的大明王朝，李定国、孙可望一批牛逼人物也拯救不了南明的覆灭，因为“结构”没变。改革开放之前与改革开放之后只有几年之差，同样一批人，为什么表现就截然不同了呢？因为结构（关系）不同了。所以，要信奉制度、信奉基本的普遍规律，尤其要遵循人性最底层的原理，否则设计的系统势必分崩离析。

信息流：系统由构件组成，系统运转离不开构件与构件之间的信息传递。这在UML当中描述成“消息序列”，其实哪怕古代军队，“鸣金收兵，击鼓进攻，旗帜指向”等信息传递方式虽然古老，但基本原理都是相同的，军事上讲究指挥各单元要做到“如臂使指”，软件系统中也同样要做到消息即时传递与反馈。

作用力：上面有提到系统内部结构，构件与构件之间相互作用力，主要改变的一是系统构件结构关系，二是改变系统构件的状态。比如，中国自隋唐开始实行科举制度，底层通过科举慢慢上升到了上层阶层，从而改变了上层贵族的组成结构，导致了庶族贵族阶级的诞生，以及强大的读书上升排队序列（士大夫阶层），从而彻底改写了中国后续的政治进程，极大地夯实了中国社会的稳固性，所以后续中国政治少了东晋世家士族“王谢堂前燕”、“四世三公”这类现象。所以在中国政治体制这个系统中，底层读书人这一个“构件”的作用力，慢慢改变了整个系统的结构，并且底层构件本身改变了“状态”，化身成为“庶族贵族”阶层新形态。而这个在软件UML系统中又分别对应对象的“多态” 和 “状态”变换。

四、如何运用UML进行系统思考

UML建模顺序，可以概括为“悬浮的冰山”，冰山上面是“需求”，冰山下面是“设计”。冰山上面是市场分析，从市场分析中提炼业务需求与契合的业务流程。冰山下面，是根据需求以及业务对象，如何抽象出代码当中的对象、如何抽象出代码的类，进而抽象出设计模式等等。

业务建模——组织要解决什么问题

                  愿景

                  业务用例图

                  现状业务序列图

                  改进业务序列图

需求——为了解决组织的问题，待开发系统应提供什么功能和性能

                  系统用例图

                  系统用例规约

———————————————水平面

分析——为了提供功能，系统内部应该有什么样的核心机制

                  分析类图

                  分析序列图

                  分析状态机图

设计——为了满足性能，系统的核心机制如何用选定平台实现

                  建立数据层

                  精化业务层

                  精化表示层

UML系统建模工作流：

如同上方所提到的，系统是分粒度的，业务系统分析就是用“上帝视角”把公司作为一个单元置身于大环境、大背景当中去进行思考，公司或组织要解决一个什么问题。解决方案竞争力如何，业务序列是否具备实际落地的可操作性。例如，老婆管私房钱，之前你买一包烟，需要问你老婆要银行卡，然后刷卡，然后买完东西，再还银行卡，这个业务序列图太麻烦。然后你发现了机会，改进了业务序列，变为你有一张特殊的卡，该卡每天有上限，你每消费一笔就有信息提示给你老婆。改进后的业务序列人性化很多，嗯，然后就有了市场，有了接受度。

水平面以上，我们运用UML思考的市场需求，是站在“卖的视角”，是一种市场的视角。怎样能符合市场预期，如何做能获得市场资产。互联网的“人头”、“注意力”是资产，能卖钱是现金，所谓产品和系统最终获取的就是市场资产。

冰山上面的系统你理顺之后，就开始深入到UML内部的进行翻译成系统语言，从业务序列中提取实体领域类，然后将领域类抽象成可代码编程的“边界类”、“控制类”、“实体类”等。

UML的工作流如图所示，它们是按照系统粒度层级推导下来的，举一个栗子：

1、业务用例   用户在投保系统中进行录入投保信息

2、业务序列   用户与系统之间如何交互，例如，输入什么有什么提示，输入什么会引起什么（如 输入身份证信息 投保系统会向第三方信用系统查询投保资质）

3、领域类图   就是用户投保过程中的序列，跟那些“实体”有交集，比如说，用户实体、第三方信用平台实体等，然后标注出来实体所包含的要素和操作各是什么。

4、理顺了上面的业务层面的东西之后，开始深入到内部，例如用户在跟投保实体交互过程中，系统用例有哪些（例如：后台查询历史数据库，保存上次信息，智能化填写以往数据等等）

5、系统用例标注出来后，针对单个系统用例，罗列出详细交互序列图，表单、边界类、控制类、实体类等等之间如何交互，如何实现。

6、最后进入OOD设计阶段，考虑用什么样的设计模式，什么样的技术手法等等。

万事万物皆成系统，皆有章序。