一个掉头发的问题：什么是建模？-技术圈

前言

本文的前两章节都是摘自《大象：Thinking in UML》这本书中，初看本书此段的时候感觉作者讲的很通俗易懂，也有理有据，但是看完了一段时间之后，再运用建模来处理工作中的复杂需求的时候，发现之前看的内容还是没吸收，没掌握，所以就再次翻阅了此书，同时将关键信息摘录了下来，同时在最后加上了一些自己的理解和解释，便于理解。

所以此文可以算是搬运，也可以算是读书笔记，大家感兴趣的建议阅读纸质书籍，不过估计应该会掉头发。

建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。上面建模的定义本身就和建模工作一样非常抽象和难以理解。

为了理解，我们简单地说：建模包含两个问题，一个是怎么建？另一个是模是什么？

一、怎么建？

“怎么建”，依赖于方法论，再上升一点到哲学高度就是认识论。

我们怎么认识和描述这个世界。唯物？形而上学？唯心？同样的事物在不同世界观的人眼里会产生不同的结果。软件针对现实世界的建模过程，也会因为“世界观”不同而不同。简而言之，就是面向对象和面向过程两种不同的软件方法将导致不同的建模结果。显然UML是面向对象的，因此用UML建模必须采用面向对象的观点，否则本来准备画一只虎，结果可能是一只猫。如果不能确定你是否在用面向对象方法去思考，可以在本书后面的实例中检验，同时也可以学习到面向对象的思维。

现在做一个快速的小测试，请在30秒内说出尽可能多的筷子，勺子和盘子的相同点和不同点。

这个问题没有标准答案，笔者在做面试的时候常常会让面试者做一下这个小测验。这个看似简单的问题其实反映了你是否习惯于以抽象的方法去看待事物。在不知不觉中，每一组相同点和不同点都来自于你的一个抽象角度。例如，当从用途的角度去抽象时，它们的相同点可能是三者都是餐具，而不同点是筷子是用于夹的，勺子是用于舀的，盘子是用于盛的；从使用方法的角度去抽象，它们的相同点都是需要用手拿的，不同的是手的动作不同；甚至可以从字面上理解，它们的相同点是都带了一个“子”字……同样这三个东西，从不同的抽象角度可以得出非常不同的结果。

实际上，抽象角度的不同决定了建模方向的不同。在抽象角度确定以后，你会在不知不觉中为这三个事物建立起模型，并据此来得出相同点和不同点。

回到软件建模上来，经过小测验后你应该明白，当你试图为现实世界建模的时候，首先要决定的是抽象角度，即建立这个模型的目的是什么。一旦抽象角度确定，剩下的事情就变得顺理成章，而不再是杂乱无章。如果对这个说法感到疑惑，请回想一下在实际项目中，当我们试图去分析需求、面对大量需求资料时，是否有时候感觉到无从下手？当我们试图去做一个设计，是否有时候感觉到力不从心？这个时候与其说是分析经验不足或是设计能力不够，不如说是你还没有找到明确的抽象角度。面向对象与面向过程不同的地方是，面向过程希望你通盘考虑，这时问题变得复杂化；而面向对象希望你把事物通过抽象角度分解成小块，问题就变得简单化。

正如同上面的小测试，在没有明确抽象角度之前，大部分面试者都会很慌张，不明白面试官为什么要问这样一个问题，不知道从哪里回答，也不知道回答得是否准确。如果加一个条件，变成请在30秒内说出在使用上筷子、勺子和盘子有什么相同点和不同点，这个问题便变得很容易回答了。读者是否也觉得这个限定条件一下子使得问题变得清爽很多？

再举一个更容易理解的例子。让我们想象一下城市里遍布的摄像机，虽然它们拍摄的都是同一座城市，但不同的机位看到的情景是不同的，每个机位都反映出了城市的一个方面。如果我们要认识这个城市，就需要先明确我们想了解城市的什么，然后选择最有代表性的机位，从各个机位采集来信息，并分析这些信息的相关性，做出逻辑解释。城市就是我们面临的问题领域，而机位就是抽象角度。实际的需要引导我们去寻找适合的机位，从而找到适合的抽象角度。再接下来，分析工作就能顺利开展了。

道理很简单，但很实用。不论在需求分析、系统分析还是系统设计上，读者一定要学会采用面向对象的方法，在面对问题领域的时候首先不要决定去通盘考虑，而是找出问题领域里包含的抽象角度。如果你把抽象角度都找全了，并且这些角度都分析清楚了，问题领域也就解决了。虽然这些抽象角度在思考的时候可能是互不关联的。

具体来说，做需求的时候，首要目标不是要弄清楚业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么？参与者的目标就是你的抽象角度。与分析一个复杂的业务流程相比，单独分析参与者的一个个目的要简单得多。实际上，这就是用例！这也就是为什么用例会成为业务建模的方法的原因之一。

二、模是什么？

“模是什么”，依赖于确定了抽象角度下的场景模拟。一旦决定了抽象角度，就确定了一个目标。现在，要做的事情便是找出那些能够满足这一目标的事物。这并不容易。有趣的是，我们找出这些事物的过程其实并不是面向对象的，而是过程化的。

这是因为要达到一个目标必须要有动作附加在静态的事物上，并产生一定的效果。这样一来，我们必须要搞清楚谁发出了什么动作，作用于什么事物，产生了怎样的后果。显然这种描述方式是过程化的。

但是与面向过程方法不同的是，我们描述这个过程化的场景并不是最终目的，而是为了找出场景当中贡献于场景目标的那些事物，以及这些事物是如何贡献于这个场景的。也就是说场景模拟帮助我们找出抽象的对象，而场景本身则是这些对象在一定条件下交互的一个特定的结果。当条件变化的时候，场景就会随之改变，我们并不试图控制这个场景。

现在回到什么是模的问题上来，一个由抽象角度确定了的目标，需要由静态的事物加上特定条件下产生的一个特定的场景来完成，即：

静态的事物（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）。

现在再问读者，模是什么，你心中是否已经隐隐约约有了答案？是的，模就是“人”、“事”、“物”、“规则”。

尽管在这里它们穿上了马甲，我们还是能够一眼认出它们的真面目来。在后面的章节里，读者将会看到“人”、“事”、“物”、“规则”还有着更多的马甲，例如人=业务主角（Business Actor）、业务工人（Business Worker）、参与者（Actor）等；事=业务用例（Business Use Case）、系统用例（Use Case）等；物=业务实体（Business Entity）、实体（Entity）等。

业务建模到底是什么，如果你还没有理清楚，图2.1中的这些公式应该会帮助你理清思路。

三、自我总结

建模是产品经理日常工作学习中很常见的一个术语，但是感觉大家对这个词的定义总是不太一样。有些人张口闭口是建模，业务建模，需求建模，功能建模……但是问他具体什么是建模，却又解释不清楚。

久而久之，建模这个词就演变成了“皇帝的建模”，大家都在说建模，但是其实大家都没见过建模是啥……

3.1 不纠结啥是建模

拿采购管理相关的需求来举例，当我们在做一个采购管理的模块的时候，我们必然会分析这个功能的使用者是谁，他可能会面临的一些特定场景是什么，以及我们要如何支撑这些场景，最后再将所有的信息串联起来，通过一系列的评估，筛选之后，确定最终要实现的内容，要满足的场景。

其实我们在做这一步的时候，已经在建模了，只不过不同的人建出来模型不太一样而已。简单理解就是，每个人对采购管理的理解是不一样的，我建的模型是A，你建的模型是B，A和B可能有一些相似性，也可能有很多不同点。如果不同点有很多，那么我们在交流采购管理这个模块的时候，大家的认知和偏好就会不太一样，甚至可能会出现南辕北辙的情况。

结合上面的这个小例子，我们再来看看文章开头对建模的定义：

建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

建模是为了获得对事物本身的理解，同时将这些理解概念化，当需要向其他人表达的时候，其他人也能快速理解，get你要传达的意思。

所以，我们不一定非要纠结“建模”是啥意思，只需要抓住建模的本质是“便于理解”和“便于传达”即可。这也可以解释，为什么有很多优秀的产品经理即使不是科班出身，压根不懂“面向对象”，“面向过程”这些内容，一样可以做好产品。

3.2 我就是想学建模怎么办？

作者在最后的时候放出来的那张图（建模公式），概括的很精炼，很到位。但是如果不看上下文还是不便于理解，不太好直接拿过来传播。我在此基础上，画了下图，希望能帮助大家对建模公式有一个更好的理解。

首先是确认抽象角度，这其实就是面向对象的一个分析过程。一个需求的背后有很多人，事，物和规则，单单拿“人”来说，也会有不同的抽象角度，例如常见的就是按职位或者使用功能的角度来抽象，采购管理模块的人分为“采购员”，“业务员”，“供应商”；但是如果按使用系统的角色来抽象，则采购管理模块的人可以分为“采购发申请角色”，“采购处理角色”，“管理员”，“采购审核人员”等。

不同的抽象角度汇聚在一起会构成“问题领域”，问题领域中那些重叠的部分其实就是需要重点关注并解决的问题，因为在不同的抽象角度都能得出此问题，则意味着该问题是高频且核心的。

其次是确认业务用例，当我们在第一步的时候确认了若干个抽象角度之后，由于抽象角度背后是场景模拟，所以我们应该对相应的场景进行梳理。例如我们是按职位或者使用功能的角度来抽象，这个抽象角度背后的场景就有“采购员在什么条件下要做什么事达成什么目标”，“业务员在什么情况下会需要发起采购申请？要如何发起？”，“在采购环节中要如何与供应商关联，关联之后能做什么”……

3.2 面向对象与面向过程

我们日常在做需求的时候，可能一开始就会陷入到特别想搞清楚业务是如何一步一步完成的，然后赶紧绘制好业务流程图，以为只要满足相应的业务流程，这个需求就八九不离十了。但是如果是一些复杂的业务场景下，业务流程图也会有很多分支，很多泳道，这个时候全部内容夹杂在一起，反而是不能很好的梳理清楚关系。这种思维方式就是面向过程的思维方式，在处理一些简单的产品需求的时候，此方法很好用。但是涉及到一些复杂的业务场景的时候，面向过程就有点吃力了，总是感觉会有遗漏，一个上游的流程发生了变化，下游的流程也可能需要跟着改。

如果我们使用面向对象的思维方式来处理复杂的需求，则首要目标并不是弄清楚业务流程，而是弄清楚有多少业务，业务的参与者是谁？参与者是目标是什么？然后再逐个分析，分别建立相应的领域模型（简单理解就是：分而治之），然后在领域模型中可以用面向过程方式去逐步细化和分析。

摘自《电商产品经理兵法：基于SaaS的电商系统设计与实践》

END