《软件方法》第8章 分析 之 分析类图——知识篇Part1（20211029更新）

墙上挂着长藤，长藤上挂着铜铃

《长藤挂铜铃》；词:元庸，曲:梅翁(姚敏)，唱:逸敏，1959

如果您在阅读软件方法时发现错误，请通过微信umlchina2通知。如果作者认为这是合理的，他决定在下次发布时根据你的意见进行修改，每个错误将支付给你5.12元报酬，并在书中说明您的贡献。微信支付报酬。

(1)任何你认为的错误都可以，包括错别字。

(2)同一错误只支付第一批正者的报酬。

(3)请根据最新版本进行纠正。

目前，下册内容包括：吴百钊、王周文、刘学斌、成文华、黄树成、李蜀斌、杨雪鸿、王书伟、高洪江、张志坚、龙烧。

从分析工作流开始，我们的每个内容都分为两章。一章讲建模知识，一章讲建模知识如何应用于本书案例。这种划分主要考虑更实用的工作。

例如，在解释分析类图时，我们按照这个顺序解释知识：

(1)识别类和属性

(2)审查类别和属性

(3)识别类之间的泛化

(4)识别类之间的关联

如果将案例分析分解到每个知识点，为了使案例分析符合内容的顺序，可能会出现这种情况：

在解释了识别类别和属性后，在案例分析中，列出了许多类别和属性，但没有泛化和相关关系，因为类别关系没有提到，所以即使观察到，也故意不画；接下来，在解释了类别之间的关系后，在案例分析中添加了关系。

这与实际工作不符。上述工作在实际工作中交叉进行。

为了避免误解，我们首先完整地解释了知识部分。如果这本书的案例与所解释的知识有关，它也将随时被引用。然后，在案例部分，根据实际工作中的思维方式灵活应用上述知识点。

8.1 分析工作流概述

8.1.1 知识的分离

在业务建模和需求工作流中，我们始终将目标体系视为一个整体，并找到推导参与者关注的整体表现-需求的方法。

为了满足需求，系统必须包装某些知识。这些知识不能从天而降，需要软件开发人员一点一点地放进去。接下来，我们将思考：

(1)如何准确表达系统需要包装的知识，使系统满足需求；

以及进一步

(2)如何合理组织系统需要包装的知识，让系统低成本满足需求。

如果知识能合理地组织知识，当新的需求到来时，准确的表达就会变得越来越困难。考虑到利润，很难留在(1)而不追求(2)。

无论是纯粹在大脑中旋转，还是借助纸笔或建模工具，上述思维都无法逃脱。如果需要包装的逻辑很简单，人脑的容量和运算速度都可以胜任，在大脑中打转可以勉强应付。然而，能够带来利润的系统是复杂的见**软件方法(上)1.8.1市场没有小系统**），借助纸笔或建模工具表达思维的过程是非常必要的。毕竟大脑容量和运算速度比普通人高一个数量级的天才是非常罕见的。

有人故意不显式地表达，声称大脑思维就够了，背后的真相可能不是天才，而是遮羞——你让他表现出来，他也表达不出来，因为他没有掌握思维方式。

思维方式，即知识分离，包括域与域之间的知识分离，以及域内的知识分离。

8.1.2 核心域和非核心域

软件系统包装了多个领域的知识，其中一个领域的知识不能被系统抛弃或替换，称为"核心域"，其为其他领域"非核心域"。图8-1显示了不同系统类型的核心域和非核心域的概念。

图8-1 不同系统类型的核心域和非核心域概念

以文档处理器为例，开发Microsoft Word和LibreOffice Writer编程语言和组件是不同的，但文档、页面、行、字等核心域的概念是相同的。这些概念仍然存在于计算机诞生之前或未来。

关于核心域和非核心域，一种常见的说法是"业务"和"技术"，但"业务"和"技术"说法不严谨。

有些开发人员在潜意识里是这样划分的:

*我知道我感兴趣的知识→技术；(我懂Java编码，我对Java对编码感兴趣，Java编码是技术)

*我知道但不感兴趣的知识→业务；(我知道一些订单、出纳和分销，但我不感兴趣。这些都是业务)

*我不懂但对知识感兴趣的知识→高科技；（我不懂深度学习，但很感兴趣，哇塞，高科技）

*我不懂也不感兴趣的东东→忽悠UML建模，也不感兴趣，妈的，忽悠)

有些开发人员是这样划分的:

*与计算机无关→业务；

*与计算机有关→技术；

核心领域不能用理解和感兴趣来判断。核心领域不一定是非计算机领域，也不一定是计算机领域，如图8-1所示。

此外，本书中的核心域和Eric Evans以及后续的DDD话语系统中的核心域(领域驱动设计)（Core Domain）意思不同。

本书中的核心域是指软件系统中不可替代的部分——这可以根据软件开发人员的知识来判断。

DDD在话语系统中，领域(相当于本书中的核心领域)被划分为"核心域"、通用子域、支撑子域等Delivery是核心，Customer是通用，Billing是支持——这个划分已经超出了软件开发人员的知识，我不认为软件开发人员有能力做出这样的判断。

购物中心之所以能击败其他竞争对手，不一定是因为订单部分不同，而是因为它在分销环节下了很大的功夫，或者客户服务做得很好。没有商业竞争的思考，武断地认为子领域是核心是不合适的。

8.1.3 域间映射与合作

域与域之间的映射和合作规律与域中的个体没有直接关系。

比如我们看一个"人员管理系统"核心域类图，如图8-2所示。

图8-2 "人员管理系统"核心域类图

若图8-2中Person类映射为C#实现可能会得到图8-3C#代码：

图8-3 类的C#实现（用Enterprise Architect映射）

将图8-2中的类映射到关系数据库中，图8-4中显示的数据库结构：

[外链图片转存失败，源站可能有防盗链机制，建议保存图片并直接上传(img-tppyCWTu-1635481657797)(https://mmbiz.qpic.cn/sz_mmbiz_png/GmehiaiamM62oH4NUUdxPWkEtJG1TtuCYwl50eJhaU5ic50WnxcHPWQq9Iib0pP2YzMugicOMcAKj4uCN5H3puVWOXQ/640?wx_fmt=png)]

图8-4 将类图映射到数据库模型(使用)Enterprise Architect映射）

如果使用某个对象-关系映射器框架(如微软)Entity Framework），Person在对象和数据库中Person表中的一行可以这样联系起来：

person1=context.Persons.Find(ID)

若在上述内容中Person改成Dog，City改成Cat，映射程序没有改变。即使我们调整了域间映射和合作程序，结果也会根据我们的调整有规律地改变，这仍然与域内的个人无关。

我们通常看到的一些架构是域间映射和合作的一些常规。图8-5是一些经常被提及的架构，可以在不同领域的系统中观察到。

图8-5 一些常见的“架构”

由于域间映射有套路，过早混合不同域的知识是不划算的。

如图8-6所示，假设三个域要考虑的因素分别是a、b、c第一，如果分开考虑，然后找到域间映射的规律，最小负担可以变成a b c；如果混在一起，大脑的负担最大化a×b×c。a、b、c都大于√3.相乘必须大于相乘。

图8-6 过早混合不同领域的知识会增加大脑的负担

单独考虑不同领域的知识并不意味着在编码前分析整个系统——害怕分析瘫痪是一种常用来掩盖分析能力不足的遮羞布。**软件方法(上):业务建模及需求1.3节**关于迭代的内容。

过早混合不同领域的知识会增加开发人员大脑的负担，导致开发人员无法腾出脑力去思考核心领域更深层次的问题。他们不得不稍微扔一下图8-5中的域间结构，安慰自己我有结构！事实上，它还没有触及最需要大脑思考的核心概念和逻辑。而这很可能被巧妙地视为遮羞布——不是我不去想，而是我想的太多了！

这种微妙微妙心态的进一步发展，开发人员会有意无意地混合不同领域的知识，使复杂性变得复杂a×b×c，以此用废话刷工作量——以最少的思考获得最多的成果。

*这几年最时髦的就是借DDD话语系统刷工作量。比如刚找到一个类别。Order，然后围一圈OrderFactory、OrderRepository、OrderService……，洋洋骄傲地把工作量刷了好几倍。*

我经常软件组织的架构师向我介绍他们所开发系统的“架构”，口沫横飞，说的基本上都是图8-5的“域之间的架构”。好啊，真棒，我知道了。还有呢？没了？

构思那些“域之间的架构”是某些厂商或者方法学家的工作，我们挑一个适合自己项目的套路用上就行了。有什么问题，可以去请教用这个套路用得好的先行者。

“域内部的架构”，那些核心域概念和复杂逻辑，这是系统最值钱的地方。要是我们没有办法理清楚，别人是帮不到我们的。这才是大脑最该用的地方！

8.1.4 应对变化，不要吃错药

平时开发人员常说要“应对变化”，甚至有的人还喊口号“拥抱变化”，但我们需要认真想一想，要应对的是什么样的变化？

我列出各种“不好了，需求变了！”的情况如图8-7。

图8-7 各种“需求变化”

第一种情况实际上是最多的：需求其实没变，只是需求人员的“认识”变了。这种由于业务建模和需求技能太差导致的“需求变化”实际上是最多的。

要应对这样的“变化”，光是有分析和设计技能是没用的，需要提升业务建模和需求技能。这种情况和本章的内容就没有关系了。

张三出现恶心、乏力、食欲减退等症状，村里的道士九叔给他诊断，认为他鬼上身了，需要搞一个驱魔仪式。九叔已经精研驱魔理论体系和实践多年，一手辟邪剑法已经练到星耀一级。

那也没用！因为张三得的是乙型肝炎。

第二种情况是第二多的：功能需求变化，包括增加了一个用例、增加了一个步骤、输入输出的字段多了一项、某个步骤的业务规则做了调整……等。如果能恰当地建模系统要封装的核心域逻辑，使得核心域模型能精确体现核心域的内涵，会大大有助于应对这样的变化。

应对第二种情况，需要提升分析技能。

如果充分了解肝脏的工作机制，当张三被诊断乙肝时，又观察到张三酗酒、熬夜，就可以预测很可能张三会肝硬化甚至肝癌，对应变是有帮助的。

第三种和第四种情况发生得就没那么频繁：质量需求和设计约束发生变化，例如响应速度、并发容量、运行平台的更换等。

一些以“领域驱动设计”为名的文章，所举例子就1-2个领域类，然后就开始讨论Entity、Service、Repository、DTO、六边形架构……不是说这个知识没用，问题是软件组织缺的是这个嘛？

这些文章以为自己在说“领域驱动设计”，其实说的是“企业应用架构模式”、“互联网系统架构模式”。

强调“领域驱动设计”，背后暗含的意思应该是缺少“领域驱动”而不是缺少“设计”，结果呢？不谈领域，谈仓储、工厂。

在一些软件开发技术大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中“域之间的架构”，而不是核心域内部的机制。究其原因也许并非不为，而是不能——架构师对自己所开发系统的核心域研究太浅。

许多“网红程序员 ”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。

说了那么多，归纳起来就是一句话：

8.1.4 重视分析工作流

分析，就是从核心域的视角构思系统的内部机理。

在现在的很多软件组织中，分析工作流的技能是非常被忽视的。很多开发人员上手就直接编码，原因并不是软件开发项目的领域逻辑简单到了不需要分析的地步，或者他的大脑比其他人发达，在大脑里就可以完成分析的工作，而是开发人员缺乏分析的技能，只好草草跳过，而且为了遮掩自己的无能，还会想各种办法来遮羞。

草草跳过的不只是分析，需求也是同样的待遇。很多需求调研就是走个形式。开发人员没有掌握需求技能，给他时间做，他也不知道怎么做，随便晃悠两下，就着急回去编码了，因为这个工作他比较熟。

用考试类比，考试时，前面几道题比较容易，扫一眼就可以写出答案。越往后题目越来越难，学霸会拿出草稿纸，列出已知条件，正推、逆推……理出解题思路，然后再答。

学渣就麻烦了，根本没有学习相关的知识和解题方法，怎么办？

遮羞利器（1）：时间。

例如，抱怨考试时间太紧张，来不及思考，只好胡乱写个答案，甚至故意提前交卷，力图给人造成一种“如果时间允许，我是能做对的”的印象——真相是，给再多的时间也不会。

对应到软件开发，就是以“时间紧”、“敏捷”为借口掩盖自己没有能力剖析复杂逻辑的事实。

遮羞利器（2）：空间。

例如，考试时故意选择不好写的笔和劣质的草稿纸，力图给人造成一种“如果纸和笔再好一点，我是能做对的”的印象——真相是，不会就是不会，给他再好的纸笔也不会。

对应到软件开发，就是借助“口头交流”、“白板”等容量小的介质，掩盖内容的苍白。白板就这么大，所以客观上你总不好意思让我用白板剖析复杂的逻辑吧？

伽罗瓦在决斗前一天晚上仓促写下自己的数学思想，不停哀叹“我没有时间了”。唉，早干嘛去了，不过伽罗瓦是真懂。

图8-8 伽罗瓦决斗前一天的手书

费马在书的空白处写下“费马猜想”，还写“我确信我发现一种美妙的证法，可惜这里的空白处太小，写不下”，估计费马是忽悠。

此处提到此二人纯属作者关于“时间”、“空间”不够的随意联想，无其他含义。

遮羞利器（3）听起来就比较高大上了：重构。

上世纪80年代末，Bill Opdyke（https://cseweb.ucsd.edu/~wgg/Abstracts/gristhesis.pdf）和Bill Griswold（http://laputan.org/pub/papers/opdyke-thesis.pdf）等人归纳了一些调整代码结构的手法，称为“重构”，后经Martin Fowler等人推广而广为流传。

“重构”的知识可以看作是建模知识的一个子集。如果开发人员真的熟练掌握重构的手法，很多情况下他已经有能力直接建模领域逻辑得到更合理的结构，根本不需要先走很多弯路再回正路。

还是用考试类比：如果考生有能力察觉某个解答的“坏味道”并“重构”，那么轮到他做类似题目时，他也应该有能力“建模”题目的各种条件，理清解题思路后直接给出正确的回答，并不需要故意做错再改过来。

如果考生别有用心把“重构”当遮羞布，结合前面两个遮羞利器，就会出现“我本来打算把我的答卷’重构’一下，但是没有时间了”，“我本来打算把我的答卷’重构’一下，但是答卷写满了没空间了”。

开发人员可以照此办理——“我先写快而脏的代码，然后再重构”，然后祭出遮羞利器“时间”（此处“空间”不好祭出）——“没想到啊，时间来不及了”。

摸着石头过河是难免的，但应该在不得不摸的时候才摸，不应该假装看不见已有的路和桥，无论大小事都主动追求摸着石头过河，而且，很多人不是假装看不见路，而是真的看不见路——就是个睁眼瞎。要是开发人员以“重构”为理由拒绝思考，很可能他的“重构”也是空话。

不过，大脑不用思考，凭感觉摸着石头过河不停刷工作量，也是一种躺平的幸福。

8.1.6 分析相关历史的简单回顾

1958年，John W. Young Jr.和Henry K. Kent发表“Abstract formulation of data processing problems”，第一次提出在独立于实现的抽象级别上定义系统的规范。

图8-9 来自 “An abstract formulation of data processing problems”（Young JW, Kent HK，1958）的截图

1959年，CODASYL（数据系统语言会议）成立。1962年，CODASYL提出了一个和Young/Kent类似的模型，称为“信息代数”（Information Algebra）。

1970-1980年代是结构化分析方法的时代，主要贡献者有Börje Langefors、Chris Gane、Trish Sarson、Tom DeMarco、Pin-Shan Chen、E. F. Codd等人。结构化分析的主要建模方法是数据流图和实体-关系图，这两者的结合，让软件开发人员有能力剖析大型系统。

图8-10 来自 Structured analysis and system specification（DeMarco T，1979）的截图

图8-11 来自 The Entity–Relationship model: Towards a unified view of data（Chen PPS，1976）的截图

1982年，Nastec公司开发出了DesignAid，这是第一款CASE（计算机辅助软件工程）工具。随后，其他CASE工具陆续出现。据PC Magazine的1990年1月30刊统计，当时已经有超过100家公司提供了将近200款CASE工具。

图8-12 来自PC Magazine 1990年1月30日刊的截图（被圈住的内容说明了工具的数量）

1980年代后期，面向对象的思想开始用于分析和设计。然后，UML统一了表示法。这部分历史已经在本书第1章“UML简史”部分讲述，此处不再赘述。

图8-13 来自 Object Oriented Analysis, 2nd Edition（Coad P, Yourdon E, 1990）的截图

图8-14 来自 Object lifecycles. Modeling the world in states（Shlaer S, Mellor SJ, 1992）的截图

8.1.7 互联网和敏捷的影响

互联网浪潮以及敏捷运动的冲击打断了分析的传承。

互联网浪潮到来之前，软件系统的竞争焦点是功能。

我1997年毕业，先到高校当了一年老师，然后才去软件公司做程序员。第一个参与开发的系统是酒店管理系统。这样的系统用的人不多，服务器一台，每个部门放上一台客户端电脑就差不多了，但功能很多，入住、退房、收银、客房，餐饮、娱乐、财务、电话计费、各种报表等等，能不能把领域逻辑理清楚非常关键。

互联网的兴起带来了这样一种系统：这种系统功能很简单，开发这种系统时需要思考的领域逻辑很少，但是这样的系统可以通过互联网让非常多的人使用，问题的关键变成了“如何在大用户量下保持性能”。

典型的例子是1996年出现的hotmail，推出一年多时间就有1200万的用户。hotmail是一个基于web的电子邮件系统，这样的系统，开发出来并没有太大难度，竞争的关键在于有没有背景、有没有钱买基础设施，有没有钱做推广……。

可能有人会说“邮件系统也有逻辑啊！”当然，这同样是一个领域，也有逻辑，但是其中的绝大多数逻辑已经被前人探索得很清楚，甚至有实际的可用组件提供，并不需要web电子邮件系统的开发人员从头思考。

很多开发人员就进入了类似的“互联网公司”，开发或维护类似的系统。因为不需要剖析复杂的领域逻辑，开发人员有没有掌握分析的技能已经无所谓，于是，很多打着“敏捷”旗号的“方法”就在这类公司大行其道，导致软件开发人员的分析能力普遍退步。

经常有人和我说，潘老师，敏捷这一套做工厂管理系统之类的可能不太行，但不得不承认，做互联网很管用噢！

当然管用了！

有个巫医发明了一种治疗方法。他坦言，我这个方法对付癌症可能不太行，但对付感冒很管用噢！你不信，找个感冒患者来！

感冒患者找来了，医生让患者躺在一张绘有八卦图案的方桌上，然后绕着患者绕了八八六十四圈（看到没，他也是有一套方法的！），然后对患者说，回去该吃吃该喝喝，五天之内就好了！

果然，患者好了。

医生四处宣传他的治疗方法，由于此方法简单易学，迅速收获了大批粉丝。

图8-15 电影《破坏之王》截图

给软件开发人员一段文字描述，让他提炼和表达其中的领域概念和关系（通过ER图、类图……甚至口述表达都可以）。基于我在训练班上的体会，能在这个测试中给出合格结果的开发人员占全体开发人员的比例，如果在2000年占百分之x的话，二十年之后的2020年，这个比例是否能占到千分之x都值得怀疑。

随着互联网的成熟，大部分组织都变成了“互联网组织”。以往以“互联网公司”著称的巨头们变成了行业领袖，宣称“我是做互联网的”已经不足以包装自己，必须要对领域深入挖掘了。

但是，开发人员“敏捷”惯了，怎么办呢？还能回得去吗？

图8-16 分析技能下降之后，还能回得去吗？

8.1.8 伪创新

于是，就出现了各种伪创新。

有的人（国内国外都有）没有掌握相应技能，也不愿意认真学习已有的知识，凭着一些朦胧的“领悟”，就“发明”了一些“新”方法，这就是伪创新。

软件开发的一些伪创新前些年打的是“敏捷”的旗号，最近几年打的是“领域驱动设计”的旗号。仔细观察，背后推动的人很多是重叠的。

伪创新，例一：

图8-17摘自2017年出版的某本名字中带有“Domain-Driven Design”的书，看起来有点像图8-9，对吧？但是图8-17的内容和绘制于1979年的图8-9比起来，水分要多得多。

图8-17 来自2017年出版的某本名字中带有“Domain-Driven Design”的书的截图

这么大一张图，除了Place Order和Ship Order这两个概念之外，剩下的就是废话刷工作量了。右半边，ShipOrder、Ship-Order、Shipping（咦？怎么没有和左边一样前面加个Order叫Order-Shipping呢，这样还可以多几个字母刷工作量）、OrderShipped，这是在上英语语法课吗？

相当于把2个概念刷了4倍工作量，得到2×4=8个结果。

信息浓度=2/8×100%=25%。

从图8-17的表示规律可以看出来，方框是workflow，进入箭头是command，出去箭头是event。既然如此，每个标签文字后面其实可以不用加“workflow”、“command”、“event”等字样，但是，不加怎么显得我工作量大呢？

考虑到这一点，信息浓度估计20%吧。或者反过来说，一条信息刷到5倍。

图8-17还有一个问题，混合了非核心域的知识，会造成之前说的a×b×c，具体在什么地方，留给读者观察。

伪创新，例二：

图8-18摘自2019年出版的另外一本名字中带有“Domain-Driven Design”的书。展示的就是打着“领域驱动设计”旗号的伪创新之一：事件风暴（EventStorming）。

图8-18 来自2019年出版的某本名字中带有“Domain-Driven Design”的书的截图

我把图8-18里提到的概念提炼出来，画了1个类和4个小人，如图8-19。数一数，包括类名称在内，图8-19一共有16个概念。

8-19 我提炼图8-18的概念画的图

有了图8-19，可以准备开车……不，准备刷工作量了！

（1）创建对象，销毁对象，刷2个蓝色纸片，就是图8-18中的Create an ad和Remove ad（怎么前面没有an了，刷得不整齐，重刷！）。

这个步骤刷出2个蓝色纸片。

（2）多重性为1的属性（从图8-18看应该是title、text和sell price），每个刷1个蓝色纸片，就是图8-18中的Change the ad title（怎么不和后面两个一致都用Update，刷得不整齐，重刷！）、Update the ad text和Update ad sell price（怎么前面没有the了，刷得不整齐，重刷！）。

这个步骤刷出3×1=3个蓝色纸片。

另外，本来这些都是Ad的属性，直接称title、text和sell price即可，不必再加前缀，但不加怎么能刷出工作量呢？一定要加！

（3）多重性为多的属性（从图8-18看应该是picture和category），每个刷2个蓝色纸片，Add***和Remove***。

这个步骤刷出2×2=4个蓝色纸片。

另外，本来这些都是Ad的属性，图8-18中写Add***和Remove***即可，不用加to Ad、from Ad，但不加怎么能刷出工作量呢？一定要加！

（4）每个操作刷1个蓝色纸片。

这个步骤刷出6×1=6个蓝色纸片。

咦？这些改变状态的操作看着怎么和属性没有什么关系呢？是属性漏了，还是操作错了？估计作者也不太了解操作、状态和属性的关系吧。

（5）把（1）-（4）步产出的所有的蓝色纸片变换词序，每个旁边加一个橙色纸片。

这个步骤结束后，得到（2+3+4+6）×2=30个方框形状的纸片，或者说，15对。

（6）把图8-18中的4个小人和每对方框任意组合，得到大约15个黄色小人。

最终，我们从往墙上贴了30+15=45张小纸片，数量和内容正好和图8-18中的纸片相同。

信息浓度=16/45×100%=36%。再考虑到那些刷上去的Ad，估计差不多33%的浓度。或者反过来说，一条信息刷到3倍。

要注意，这仅仅是其中一个类Ad，其他类照此办理，今年的工作量可算是有交代了。

是不是创始人英明神武，只不过其他人把经念歪了？感兴趣者可以去自行看“事件风暴”的作者Alberto Brandolini的书，看看书里面讲了什么。

*调查：您看过的以“领域驱动设计”为名的文章，有类似的刷工作量的情况吗？

有

没有

这些伪创新在思想上都有共同的错误：一一对应，内外不分。

世界之所以复杂，或者说，系统之所以复杂，就是因为很多关系不是一一对应的。

组织的一个流程可能由多个系统（包括人肉系统和非人系统）协作完成，一个系统可以参与组织的多个流程；系统的一个用例（如果读者没有掌握上册讲解的用例的知识，就当作是功能吧）可能由系统的多个类协作完成，一个类可以参与系统的多个用例。类的一个操作可能会影响多个属性，一个属性可能会被多个操作影响……

正是因为如此，才需要软件开发人员大脑来找出最佳的映射方案，这才是人的脑力需要花费的地方。

而这种思考是有一定门槛的，不是所有人都能胜任。

如果一个人不能胜任，而又不愿意花时间去学习，当有一种“一一对应刷工作量”的伪创新出现在他面前时，自然而然就会产生一种虚幻的“受用”感觉，欢快地投入伪创新的怀抱——

“哥也是有方法的人了！”

最近几年的微服务浪潮中，类似“以用例为依据分割系统”甚至“以业务流程为依据分割系统”等明显内外不分的言论为什么能流传开，就是因为足够简单，方便一一对应刷工作量。

***********

初中数学里要学习全等三角形、相似三角形、SSS、SAS……，到了高中以后学了正弦定理、余弦定理等解三角形的知识……就不会再回去用初中的方法解题了。

但是，不是所有人都能学会高中的知识，比如说张三。

张三可能会这样解释：

“我这个人能力比较弱，只能掌握全等三角形、相似三角形的方法。”

这样的说法没有问题。

张三还可能会这样解释：

“这个题目比较简单，用全等三角形、相似三角形的方法做足够了，而且这样更方便广大人民群众理解。”

这样的说法也可以。不过，竞争对手不是傻子，市场中哪里有什么"简单题目"！能带来利润的题目都很复杂。

但是，张三如果这样说：

“全等三角形、相似三角形的知识比高中三角函数的知识更深刻。”

这就是自欺欺人了。

更要警惕的是，有一个李四，也许和张三一样没有掌握高中方法，也许掌握了高中方法但是为了忽悠张三们，偷偷把"全等三角形"改名为"叠合三角形"，然后和张三宣传：

“我发明了"叠合三角形"新方法，比高中的三角函数有用，三角函数过时了。”

这就是可恶了。

***********

回到前面举的伪创新例子。如果说熟练掌握类图、状态机图等建模技能，并发现了其中的缺点，站在前人的肩膀上创新，这个要举双手双脚支持。

在不了解已有知识的情况下，拍脑袋搞出伪创新，甚至向大众宣传伪创新，也是个人自由。

但是，宣传伪创新时，像上面李四那样胡说“我这个方法比***好”，就不对了。

事实上，一旦付出努力，咬咬牙掌握了更严谨和更高效的方法，是羞于再回头去使用那些打着“敏捷”或“领域驱动设计”旗号的伪创新的。

8.1.8 本书使用的分析方法

分析模型描述系统要封装的核心域知识。

至于用什么建模概念来思考和描述核心域知识，可以有很多种选择。例如，“人”用不同的建模概念描述，可以说它是一个“类”，也可以说它是一个“类型”、一个“实体”。

本书使用面向对象的建模概念来描述分析模型，从三个视角来描述：

分析类模型：描述系统中各个类以及类之间的关系。

分析状态机模型：描述某个类的各个行为的逻辑。

分析交互模型：描述某些类在实现某个用例时的协作。

而面向对象的分析模型的表达形式，也可以有多种选择：语音、文本、图形等。

有的人觉得当前许多编程语言的表达能力已经很强，认为用文本已经足够，抗拒用图形来表达领域知识。

但是，和只有自上而下顺序的文本相比，能够朝四个方向扩展的平面图形（如果有三维模型就更好了）更容易让建模人员看出领域概念之间的联系。例如，图8-19和8-20的内容，如果没有图形的帮助，直接用文本一行一行地构造分析模型，人脑的负担非常重。

图8-19 餐饮领域的类图

图8-20 来自 Practical UML Statecharts in C/C++（Samek M, 2008）的截图，计算器的状态机图

说到这里，又不可避免地要提醒，故意选择文本的形式来表达领域知识，有可能也是一种遮羞利器。图8-19和8-20的内容如果用文本表达，可能会得到很多页文本——这就有了理由：因为工作量太大了，所以很多地方无法做深入的思考，可以原谅！

本书使用类图、状态机图和序列图三种UML图形来表达面向对象的分析模型。UML类图表达分析类模型，UML状态机图表达分析状态机模型，UML序列图表达分析交互模型。

图8-21 本书的分析方法所使用的UML图形

需要说明的是，虽然我们用的是面向对象的分析方法，也就是说，用面向对象的概念来剖析核心域知识，但不意味着你的系统一定要用特定的“面向对象”编程语言、特定的存储方式或物理分布形式来实现。

也许你使用的编程语言是面向过程语言，例如C；也许你使用的编程语言是函数式语言，例如F#；也许你使用的存储系统是关系数据库系统，例如SQL Server；也许你使用的存储系统是非关系数据库系统，例如MongoDB；也许你的系统运行在同一台机器上，也许是分布在很多台机器上……

不管你的系统的实现方式和运行形态如何，从分析过渡到设计时，变化的只是分析到设计的映射套路。如果设计所使用的非核心域比较“面向对象”，那么映射套路会比较直观一些，否则，就需要一定的转换。但无论如何，如前文所说，这个套路和具体的核心域知识没有关系，我们并不需要针对每一个核心域概念逐一花费脑力去思考它。

我们之所以选择在分析工作流使用面向对象的分析方法，是因为从思考深度和表示的严谨程度来看，面向对象的分析方法以及UML表示法目前仍然是剖析和整理领域逻辑的最佳选择。

本书在设计工作流的内容，会展示分析模型和各种实现方式的映射套路。

扫码或访问http://www.umlchina.com/book/quiz8_1_1.html完成在线测试，做到全对以获得答案。

1. [多选]关于分析和设计的区别，以下说法不恰当的有：

A) 分析着眼于“系统做什么”，设计着眼于“系统怎么做”。

B) 分析和设计分离的好处是，先全局思考整个系统的各个类以及类之间的关系，再有规律地映射到实现的平台和语言，这样就减少了反复试错的成本。

C) 有时候，在分析工作流也会考虑内存、网络带宽等概念。

D) 分析注重业务，设计注重技术。

2. [单选]掌握MVC、MVP、MVVM、六边形、洋葱型……等模式或架构，并不能解决分析的问题，原因是：

A) 它们描述的是域之间的协作。

B) 它们没有得到广泛使用。

C) 它们没有体现面向对象的思想。

D) 它们不够敏捷。

3. [单选]以下（1）-（4）所展示内容的共同点是：

（1）

（2）

（3）

（4）

产品愿景：为了满足内外部人员，他们的在线订餐、自动订餐统计和外部人员管理的需求，建设这个在线订餐系统，它是一个在线订餐平台，可以自动订餐统计。它可以同时支持内外网订餐，同时管理内外部人员订餐和定期订餐分析。

A) 都是UML模型

B) 都有废话内容

C) 都涉及到电子商务领域

D) 都体现了面向对象建模的思想

4. [单选]第一款CASE（计算机辅助软件工程）工具是：

A) Rose

B) ERwin

C) FlowChart/360

D) DesignAid

5. [单选]“领域驱动设计”体系中有“限界上下文”的概念（类似于UML的组件）。有的人提出以功能（或用例）为依据划分上下文，有的人甚至提出以业务流程为依据划分上下文。这些做法的主要问题是：

A) 没有区分核心域和非核心域

B) 内外不分

C) 没有使用UML的标准符号

D) 不够敏捷

6. [多选]以下说法正确的有：

A) 用核心域术语表达的内容就是分析模型。

B) 分析模型概要地描述核心域知识，设计模型将核心域知识细化。

C) 面向对象的分析模型不妨碍使用面向过程的设计。

D) 口头表达也可以表达分析模型。

7. [单选]有一篇文章，作者在白板上画了一个类图，然后开始掰着指头数这个类图缺什么，“没考虑到持久化”，“没考虑到对象的创建”……然后得出结论：画这个类图不如直接编码。根据本节的知识，以下正确的说法是：

A) 作者不了解核心域和非核心域分离的重要。

B) 别急，这个图会越来越细，逐渐添加作者认为缺少的那些东西。

C) Talk is cheap. Show me the code.

D) 敏捷是建模的精髓，加上这些就不敏捷了。

8. [多选]有开发人员说“现在开发一个应用真容易，咔咔咔几下，绝大部分工作框架都帮你弄好了，只要添加一些业务代码就可以了”，从本节的知识点评价这段话，以下说法正确的有：

A) 这段话的背后是一种无利的思维。

B) 这个说法太片面，有的业务是比较难的。

C) 非核心域的复用竞争对手也容易获得。

D) 这正是敏捷开发的优势。

9. [多选]以下描述的系统中，适合用面向对象的分析方法做领域建模的有：

A) 电磁轨道炮武器系统

B) 互联网拼单购物系统

C) PC单机角色扮演游戏

D) 电梯控制系统

8.2 建模步骤3-1 识别类和属性

8.2.1 面向对象的假设

当使用面向对象的方法来分析系统时，我们假设系统由"对象"这样一种东西构成，对象封装了数据和行为。

在分析工作流，我们认为系统中的对象在一个虚的"对象空间"中运行。这个空间不是内存，也不是硬盘，只是人脑中的一个逻辑空间，将它想象成宇宙空间也未尝不可。在"对象空间"中，速度不是问题，对象的创建和对象之间的通信都非常快。

图8-22 虚的"对象空间"

以上内容可以用来判断你思考的问题是分析问题还是设计问题。

我们可以针对分析模型里的元素，一个一个问“如果性能不成问题，速度无穷快，这个东西还有必要存在吗”，如果答案为否，那么从分析模型中把它删掉。

分析模型受到设计的污染，很容易导致批量的废话刷工作量，导致没有时间思考应该思考的问题（当然，这也可能是某些人乐意的）。

注意上文提到的"假设"二字。面向对象就是一个假设，如果不认可“系统由对象构成”，也可以分析系统的核心域逻辑，只不过用的方法不叫“面向对象方法”。

面向对象的思考方式比目前的其他思考方式要好一点，原因不是计算机喜欢面向对象或者面向对象更接近于计算机的底层，而是面向对象的思考方式更能帮助人脑去剖析复杂问题——估计计算机更"喜欢"人类用机器语言直接给它发指令，不用自己受累编译、链接。

正如前文提到的，三角函数更能解决复杂问题，不意味着它比全等三角形、相似三角形更容易掌握。面向对象更能帮助剖析复杂问题，不意味着面向对象的思考方式比其他的思考方式更容易掌握，而且随着你掌握了更强有力的思考工具，更复杂的问题就会扑面而来。这些问题之前已经存在，只是之前你没有能力来发现和对付它们——“古人很少死于癌症”。

在接受“面向对象”假设的前提下，我们接下来就要做第一步思考：系统由什么样的对象构成。

在这一步思考中，我们通过抽象思维把具有共同特征的对象集合归纳为"类"，对象看作类的实例。

归类是人类认知的一种基本技能，其哲学讨论可以追溯到柏拉图的理型论（Theory of Forms）。

8.2.2 三种分析类

依照Ivar Jacoson在“Object-Oriented Software Engineering: A Use Case Driven Approach”（Jacobson 1992）中的思想，在分析工作流我们进一步假设系统中存在三种类：边界类（Boundary Class）、控制类（Control Class）和实体类（Entity Class）。

在模型中，我们可以用Ivar Jacoson建议的构造型（Stereotype）来表示三种分析类，如图8-23。

图8-23 三种分析类的构造型

一些UML工具（如Enterprise Architect、Visual Paradigm）已经内置了这些分析类构造型。如果使用的建模工具没有内置这些构造型，可以自己添加如“<<边界>>”等文字构造型；或者不用构造型区分，通过给类起名"某某接口"，“某某控制”，也有助于了解该类在系统中扮演的角色。这一点，和第3章讲到业务工人、业务实体时的做法是一样的。

三种分析类只是一种逻辑上的思考方式，如果你乐意，可以换成另外的思考方式。在设计工作流，三种分析类可以映射到任何实现架构，包括但不限于MVC、MVP、MVVM、六边形、洋葱型……甚至映射到不做任何分割的“架构”。

图8-24展示了三种分析类的责任、和需求的关系以及命名。

图8-24 分析类的责任、和需求的关系以及命名。

8.2.2.1 关于边界类

边界类的责任是接受输入、提供输出以及做简单的过滤。

图8-24中提到边界类的映射方法——每个有接口的外系统映射一个边界类。这里说的"有接口的外系统"不仅包括系统执行者，还包括仅接受系统输出信息的外系统。

以《软件方法》上册案例中的"时间→发送公开课通知"用例为例。该用例进行过程中，系统会向软件开发人员发送公开课通知，同时还要向UMLChina助理反馈发送通知的进展。软件开发人员和UMLChina助理在这个用例中仅仅是接受输出，没有输入信息给系统，但系统可以分别设置一个边界类来封装向软件开发人员和UMLChina助理反馈信息的责任，如图8-25所示。

图8-25 外系统映射边界类

图8-25中，“时间”映射一个“时间接口”，“软件开发人员”映射一个“软件开发人员接口”，“助理”映射一个“助理接口”。

分析工作流的边界类不暗示任何实现方案。在总责任相等的前提下，它和实现的映射是多样的，可以用图形界面实现，也可以用非图形界面（包括文本、声音……）实现。

即使使用图形界面实现，也不能简单认为一个边界类对应一个窗体（Form）。一个边界类的责任可以拆解到多个窗体上，一个窗体也可以和多个外系统交互。如何组织这些责任，应该从外系统的角度来考虑，而不是从用例或实体类的角度来考虑。

图8-26中，“助理接口”边界类被圈住的几个责任来自不同用例的步骤，但在使用图形界面实现时，可以放在面向助理的、通知专用的同一个窗体中。

图8-26 边界类责任的组织

类似的例子还有：一份申请，需要通过系统审批三次，也就是三个不同的用例。在图形界面实现中，可能不需要准备三个窗体，部门主管、财务、副总三个审批人可以在同一窗体上工作，但部门主管、财务、副总各自有对应的分析边界类。

如果某个外系统和系统的交互很多，对应边界类的责任可能会有很多。另一种做法是按"外系统+用例"的组合映射边界类，这样可以减少一个边界类上的操作个数。不过，这样的做法已经暗示“按用例来划分边界”，所以还是建议尽量保持一个外系统一个边界类，如果操作很多，可以将从外系统角度观察可能要分在一组的操作移到一起，EA等工具可以随意定制属性和操作的上下显示顺序。

需要提醒的是，外系统映射的只是边界类，并不映射实体类。在外系统是人的时候，经常会有人犯这样的错误。例如以下用例规约片段：

1. 助理选择公开课，请求创建通知任务

2. 系统验证所选公开课适合创建通知任务

“助理”是执行者，映射一个边界类“助理接口”是可以的，但如果映射一个“助理”类，如图8-27，那就错了。

图8-27 外系统不映射实体类

系统是否需要一个“助理”类，要看系统是否需要维护助理的信息。如果需要，会在某个用例规约的某个地方体现，例如，可能会有一个步骤：

7. 系统保存通知任务

绑定一个字段列表：

7. 通知任务=4+创建时间+创建人

这个“创建人”就是助理，说明系统需要记住助理的信息，这时才会有“助理”类。

但并不是所有的系统都会这样。例如，乘客坐电梯上楼，乘客是电梯系统的执行者，但电梯系统可能不需要"乘客"实体类，因为它不需要记住乘客的信息。

当然，有朝一日，电梯升级为防疫电梯，用例规约里有：

4 乘客提供身份标识

5 系统验证身份标识合法

6 系统记录乘客信息和入厢时间

这时，电梯系统里就有"乘客"实体类了，因为系统要记住乘客的信息。

电梯系统虽然没有"乘客"类，但会有"乘客接口"类，可能的类图和常见的实现方式如图8-28。

图8-28 “乘客接口”及其常见的实现

8.2.2.2 关于控制类

控制类相当于用例在系统中的“代理”，它的责任是控制用例流，为实体类分配责任。

把每个用例直接映射一个控制类，可以用“用例名称+控制”来命名，后面的“控制”二字最好加上，因为可能还有记录行为细节的实体类，名称和用例的名称一样。例如，用例名为“审批”，控制类起名“审批控制”，如果需要记录审批的细节，还会有一个实体类“审批”。

如果在分配责任时发现控制类只起到传递的作用，没有起到分解和分配的作用，也可以把控制类去掉。

8.2.2.3 精力应该花在实体类上

边界类与外系统、控制类与用例的映射关系很明显，所以识别边界类和控制类不需要思考，直接按照上面的套路映射即可，甚至可以推迟到画分析序列图时再加上去。

有的分析方法学如ICONIX提倡一种Robustness Diagram，认为可以通过它来帮助寻找类。开发人员一用确实感觉很舒服，噼里啪啦就发现好多类，有一种"我已经取得了不小成绩"的错觉，不过要是仔细看看，就知道"发现"的多是边界类、控制类。这些类其实用不着刻意去发现，只要按照图8-24的套路映射即可。

最难的工作——寻找实体类以及它们之间的协作，Robustness Diagram却是寥寥带过，甚至容易误导建模人员把实体类和用例一一对应。所以，本书不推荐开发人员额外花时间画Robustness Diagram。

和前文多次提到的一样，凡是不需要思考就可以得到很多“成果”的“方法”，都容易成为懒人摸鱼的遮羞布。

建模人员的思考工作量应该花在识别实体类上。一个用例需要哪些实体类协作实现、如何协作，一个实体类会参与哪些用例的实现，这是一个多对多的映射，需要由建模人员的大脑决定哪种映射最好。

8.2.2.4 分析类的协作

图8-29展示了三种分析类之间的协作。

图8-29 三种分析类在系统中的协作

执行者先把消息发给边界类对象，边界类对象能履行的就履行，无法履行的责任，再发给控制类对象。控制类对象就像总裁办，不做具体工作，只是将责任分解后分配给实体类对象。

实体类可以按照它们之间的耦合程度组成若干组合（Composition），类似于公司的部门。组合之间还可以再组成更大的组合，类似于大部门中有小部门。也有可能有的类既不组合其他类，也不被其他类组合，类似于自成一个部门。

控制类对象发送消息时，先发给组合的整体对象，再由整体对象分配（可能还有分解）给组合内的其他对象，如果组合内的对象还组合了更小的对象，还可以继续分配。最后，由边界类对象反馈信息，完成一个交互回合。

以上说的“组合（Composition）”和DDD话语体系中的“聚合（Aggregate）”是类似的。面向对象的分析设计方法学早已有Aggregation、Composition的概念，Eric Evans在塑造DDD话语体系时借用了Aggregation一词，其实借用Composition更合适。关于这一点，本书在讲述类的关系时会详细说明。

8.2.4 在建模实体类之前-区分一些概念

对于一些用语，本书按以下定义使用。

领域模型：描述某个领域中的概念及概念之间关系的模型。

分析模型：从核心域视角描述的软件系统的模型。

核心域模型：等同于分析模型。

模型可以用各种表示法来表示，相应的图可以叫“领域类图”、“领域ER图”、“分析类图”、“分析状态机图”……。

如果按照本书所采用的面向对象建模、UML表示法和Ivar Jacoson三种类的分割，某个领域模型可能会包含某个系统的分析模型中的实体类部分，但不会包含边界类和控制类部分。

画类图的工作，并非只是在软件开发的分析工作流中才会做。第7章“需求启发”中就提到，我们在研究资料的时候，可以通过画类图来整理领域的概念。整理领域概念时，有时还可以加上状态机图（但不会使用序列图，自行思考一下为什么）。即使不是为了开发软件，也可以通过这些手段来整理领域知识，帮助我们更快掌握。

******

软件开发也是一个领域，在阅读软件开发资料时，同样可以通过画类图、状态机图等来整理领域概念。

我们就以阅读《软件方法》为例。在阅读时，看到如图8-30的内容，即《软件方法》第2版第2章第35页。我们用类图整理概念，可能会先得到图8-31。

图8-30 《软件方法》第2版第2章第35页

图8-31 整理领域概念得到初步的类图

如果建模技能掌握到位，可以把图8-31稍微改进一下，得到图8-32。

图8-32 改进后的类图

图8-32表达了《软件方法》这一部分内容的领域知识，或者说软件建模领域的一小部分领域知识，可以称为软件建模领域的领域模型。不管有没有打算用某个软件系统来封装这些领域知识，这些知识都是摆在那里的。

如果打算用某个软件系统（例如后文将提到的“发糕”智能建模工具）来封装图8-32模型的部分或全部知识，可能会得到图8-33。

图8-33 某软件系统的分析模型

可以看出，图8-33是图8-32的一部分。该软件系统（即“发糕”智能建模工具）不打算封装哪个组织是哪个组织的客户，哪个人员是哪个组织的开发人员……等知识。图8-33可以看作该软件系统的分析模型（核心域模型）。

注意我们的用词——软件建模****领域的领域模型、该软件系统的分析模型（核心域模型）。

图8-32、图8-33都可以称为软件建模领域的领域模型，因为它们确实描述了软件建模领域的某些概念及概念之间的关系。

图8-32不是“发糕”智能建模工具的分析模型，因为“发糕”不打算封装图8-32中的所有知识。

图8-33是用iOS上的“备忘录”系统画的，但图8-33不是“备忘录”系统的分析模型。“备忘录”系统的核心域概念应该是“笔”、“颜色”、“图片”等。

我们可以注意到，图8-31至图8-33都比较粗略，例如类没有属性、关联没有多重性等，但不妨碍对它们的定性。

******

有些书籍和文章作者，对软件开发的工作流没有清晰的概念，把所有用“业务语言”表达的模型，包括组织流程，系统需求规约等，通通叫作“领域模型”。这是不正确的，我们在阅读时要注意分辨。

8.2.5 提炼实体类和属性

从上一节我们了解到，可以从各种素材中提炼某个领域的类和属性，不过这些类不能叫分析类，只能叫领域类。到底哪些领域类会成为目标系统的分析类，需要从目标系统的需求模型（如果用本书的方法表达，就是系统用例规约）来判断该系统是否需要这个类。

没有需求规约，目标系统的边界以及应该承担的责任没有理清楚，那么，提炼得到的类到底是不是目标系统将来需要维护的概念，是没法判断的。也就是说，虽然在很多时间点都可以提炼类，让我们在确定分析类时，省去了许多思考，但分析模型的最终依据只能是需求模型。

当然，如果你脑子里对于系统该干什么不该干什么清清楚楚，只不过没写出来，那也算是有需求模型了——不过你得确定你真的懂，而不是拿这个当遮羞布。

如果之前没有从其他素材提炼类和属性，而是在需求工作流结束之后，从系统用例规约提炼，那么该怎么做呢？

阅读用例规约的基本路径、扩展路径、字段列表和业务规则部分（即所谓“功能需求”部分），针对表示名词或事件的词汇，逐个思考，**这是不是系统要记住的核心域概念？**如果是，那么它是类，还是某个类的属性？如图8-34。

图8-34 从用例规约识别类和属性

关于“系统要记住的”概念，可以这样思考，在执行者向系统发出某个请求之前，系统需要懂得哪些信息？

如果您有关系数据库建模的经验，也可以这样简单地思考：如果系统采用关系数据库来保存这些内容，那么数据库里应该会有哪些表？这样思考得到的表和实体类基本上是一一映射的。表对应类，列对应属性，行对应对象，关系对应关联。后面我们会讲到，类模型可以直接转换成关系数据库模型，不需要再花工作量再做一遍关系数据库建模。

如果关系数据库建模技能掌握得好，得到的数据模型符合1NF、2NF和3NF，那么用关系数据库建模的思考方式得到的类图极有可能也是合格的。反过来，也有理由怀疑，自诩关系数据库建模能力强的人，如果类建模做得乱七八糟，估计也有吹牛的成分。

当然，我们画类图的目的不仅是为了得到关系数据库，面向对象和关系数据库（或任何的具体存储方式）也没有必然的绑定关系。任何系统都可以用面向对象的方式来构造，不管它用什么方式来存储对象。

以电梯为例。我们把为乘客提供电梯服务所需要的所有软硬部件看作一个整体，称为“电梯系统”。乘客在发出某次召唤之前，电梯系统要懂得各部电梯当前运行方向、当前所处楼层、待去往的目标楼层集合以及楼层的结构，才能够合理应对乘客的召唤。这些可以看作系统要记住的信息。乘客姓名、乘客召唤电梯的时间、电梯曾经去过的楼层等，系统不需要知道。画出类图如图8-35。

图8-35 电梯系统可能需要的实体类

这些信息不一定需要被“持久存储”。图8-35中的概念中，当前楼层、目标楼层、方向的信息一直在不断变化，甚至在电梯系统停止服务时会被清空，但不影响图8-35的类结构。

8.2.6 类和属性的命名

8.2.6.1 使用精确的领域术语命名领域模型中的元素

领域模型中各个元素的名称都应该来自该领域的术语体系。

一个领域之所以能作为“领域”为人认知，必定会在发展过程中沉淀出一套日益完善的、精确的术语体系。每个术语有其独特的、其他术语不能替代的含义。例如物理学中的质量、重量、重力、引力、衰变、裂变、聚变……，各自有各自的含义，不是另一个概念可以取代的。

涉众常使用的词汇不一定适合用来命名领域模型中的元素。

也许是出于自己的领域知识局限，或者出于字数少使用方便，涉众有时更习惯于使用一些不严谨、感性的称呼。

这些称呼经常会根据颜色、大小等感性认识来起名。例如，货车司机可能会把一张单子称为“绿单”，因为单子的颜色是绿色的，但更精确的名称可能是“送货单”；购物时的“小票”，名称来源于面积较小（和更大的“发票”比较），更精确的名称可能是“收据”。

这些称呼所依赖的信息，稳定性往往比真正的领域内涵要差。有关机构可以改变送货单的颜色，购物收据也可以变成面积比发票要大的大长条，“绿单”、“小票”等称呼就得变化了。即使已经形成了习惯不得不一直沿用下去，真实的情况和字面的意思已经大相径庭。

涉众喜欢用不严谨的称呼，这是正常的。某类涉众的领域知识可能会很片面，对领域概念认识不深刻，怎么能寄望一个使用探探来交友的屌丝青年清楚社交六度空间理论呢？正如第7章所说，涉众关注的是涉众利益，不能指望涉众提供需求，更何况是分析了。精确使用领域术语是建模人员的责任，不是涉众的责任。

当然，在和涉众交互的界面上，依然可以针对不同的涉众使用涉众习惯的不严谨称呼。

涉众有很多种，不同类型的涉众可能对同一概念使用的称呼不一样，例如有的叫"宝贝"，有的叫"商品"。如果怀疑两个称呼描述的是同一个概念，可以这样问：有没有不是商品的宝贝？有没有不是宝贝的商品？如果回答都是否，就清除掉其中一个，否则，应该继续研究两个称呼背后的真正含义，必要时在模型中表达其中差别。

如图8-36，左侧的几个概念中，经过审查，认为"宝贝"和"商品"、"顾客"和"客户"含义相同，去除其中一个；“用户”、“顾客”、"会员"含义有差别，在类图上更精细地表达。

图8-36 清理冗余的称呼

8.2.6.2 不胡乱发明“新”术语

建模人员要尊重并认真学习领域的已有知识，不要胡乱搞术语“创新”。

互联网是术语“创新”的重灾区。赋能、抓手、对齐、拉通、打法、链路……这些胡乱创新的“术语”，难道之前没有合适的词汇来描述吗？非也，有心人就是要通过这样的“创新”，割裂和已有知识的联系——我是“新”的，不受已有知识的约束，所以我不用花时间学习已有知识，随意胡说就行了。

上个世纪末，互联网的创业者们纷纷宣称自己是“新经济”，意思是以往的经济规律对我没用。

Shapiro和Varian在“Information Rules: A Strategic Guide to the Network Economy（信息规则：网络经济的策略指导）”一书中说：

we kept hearing that we are living in a “New Economy.” The implication was that a “New Economics” was needed as well, a new set of principles to guide business strategy and public policy. But wait, we sa