分析之分析类图—知识篇Part06（202205更新）

Posted 2022-06-30 UMLChina潘加宇

8.2.4.3 核心域透镜

在为了软件开发而建模时，建模人员可能会用自己熟悉的非核心域术语来代替不那么熟悉的核心域术语，还引以为豪。例如，面对一段集装箱领域装箱规则的描述，建模人员立即在大脑中把它转换成自己熟悉的概念：栈、链表、树……而且认为这是“透过现象看本质”，甚至宣称“我就是程序，程序就是我”！

Fred Brooks在《人月神话》中引用了James Coggins的一段话：

The problem is that programmers in O-O have been experimenting in incestuous applications and aiming low in abstraction, insteadof high. For example, they have been building classes such as linked-list orset instead of classes such as user-interface or radiation beam or finite-element model.

问题是面向对象程序员在开发错综复杂的应用时，关注的是低层次，而不是高层次的抽象。例如，他们开发了很多像链表或集合这样的类，而不是用户界面、射线束或者有限元模型。

不同领域有不同的难题，因为觉得困难，所以对真正要解决的核心域问题视而不见，却花精力去做那些自己熟悉的、他人已解决的非核心域问题，是一种逃避。

为了避免核心域概念被非核心域概念掩盖，我们可以采用一种如图8-59所示的“核心域透镜”的思考方式：如果从核心域的视角去看这个概念，或者说把这个概念映射到核心域，我们应该得到什么概念？

图8-59 用核心域透镜映射各种概念

例如，以“学习和考试”作为核心域，经过透镜前后的概念对比如图8-60。

原描述	映射后的核心域概念	原描述过去变体	原描述将来变体（猜想）
PowerPoint	演示工具	黑板、玻璃幻灯片、赛璐珞幻灯片	全息
检查IP地址	检查重复听课学生	看脸、看签名	检查另一种协议地址 检查大脑芯片标识
点击“开始”按钮	开始考试	观察到考生开始书写	？
向数据库“答题”表添加一条答题记录	答题	在答卷上涂黑一格	？

图8-60 经过透镜前后的概念对比

对每一个用语我们都可以这样过一下：这个用语属于核心域概念吗？如果不属于，映射到核心域概念意味着什么？

例如，图8-61左侧，“商品”有一个“加粗显示”的属性来标记它是否加粗显示。如果核心域是“商品”相关的领域，那么“加粗显示”不属于核心域的概念。我们可以追问：为什么要“加粗显示”？回答可能是：因为该“商品”是“热销商品”。“热销”才是核心域概念，可以改成图8-61右侧。

图8-61 “加粗显示”的映射

这里面涉及到两个知识：

知识一：某商品是热销商品。这是商品领域的知识，已经存在很多年。

知识二：如何表示“热销”的概念。这和表示方式、时代审美、展示的目标人群等有关。图形接口的表示和文本接口、语音接口不同，十年前的图形接口和现在的图形接口不同，面向年轻人的图形接口和面向老年人的图形接口不同……

8.2.4.4 命名中不带冗余内容

如果把模型元素命名中的某个部分删去，不影响建模人员对该模型元素的认识，那么这个部分没有必要存在。

如图8-62中，在“人员”后加一个“类”字，实际上也是把两个不同领域的知识叠加在一起。

知识一：人员是一个类。

知识二：用UML表示法的图形表示，类是一个方框。

知识一和知识二是正交的。在对知识二已经有了共识的情况下，再加上一个“类”字是冗余的。

图8-62 删除命名中的冗余部分

关于类和属性的命名，常犯的冗余错误有：

（1）在类名的最后加"类"字；

（2）在类名的前面加"Class"或"C"；

（3）在类名的最后加"情况"、"信息"、"记录"、"数据"、"表"、"库"、"单"等；

（4）在属性名前加类名

如图8-63，按"类的属性"念出来，"人员的姓名"很好，"人员的人员姓名"就冗余了。

图8-63 属性名称前不需要加类名

（5）给类加上标识属性

对象有标识，这是一个共识，不需要为类专门加一个如“**ID”之类的标识属性。

如何表达对象的标识，这是另一个领域的知识，其实现规律和当前所研究领域的知识无关（除非当前所研究领域就是“如何实现对象标识”的领域）。一旦确定实现的套路，在设计工作流通过人工或工具按照套路加上即可。

此处说的标识是为了区分对象而添加的标识，在设计工作流中可以以整数、GUID等各种方式实现。它应该不带任何领域知识，因为一旦带有领域知识，就意味着一旦领域知识发生变化，它也要跟着变化。

除了标识之外，可能还有其他在类的对象集合内值唯一的“编号”属性，如订单编号、人员身份证号、房间号等。这些“编号”属性往往带有领域知识，例如房间号“203”会暗示这个房间是2楼第3个房间，这样的暗示，是为了让人方便记忆和识别，计算机并不需要标识中含有领域知识，除非对象没有其他属性，把各种领域知识都凝结在标识中，需要计算机来解析。

在设计工作流，虽然这样的属性也可以作为标识使用，但尽量不要这样做，因为其中的领域知识一旦发生变化，就会带来风险。

本书作者的身份证号，最开始是15位的“3401**74******1”，1999年升位，变成了18位的“3401**1974******19”。身份证号中暗示了许多知识：3401**→安徽省合肥市蜀山区，1974****→1974年**月**日生，**1→当日出生的男性顺序号，9→校验码。这些信息发生变化时，原有的暗示就失效了。

对象标识仅在内部用于表示对象，不需要在人机交互的界面上出现，也就是说，不需要人类执行者输入对象标识，也不需要向人类执行者展示对象标识。如果需要，在人机交互的界面上出现的应该是“编号”属性。

*********

如果犯了以上所列举的错误，相当于强行把正交的知识叠加在一起，往往就会得到“废话刷工作量”的结果——记住这个要诀，如果有一天读者想要故意“废话刷工作量”，就把它用上。

举个“废话刷工作量”的例子以加深印象，如图8-64，如何“废话刷工作量”？

图8-64 无冗余的类图，等待“废话刷工作量”

按照上面提到的冗余错误，一个个用上去，可以得到“废话刷工作量”的步骤如下：

（1）因为方框上部是类名，下部是属性，连线是关联，所以，给类和关联的名称加上“类”、“属性”、“关联”。

（2）可以看出，这些类是领域类或分析类，所以，把“领域”加到类名称后面。

（3）因为这些类都代表了一些信息，所以，把“信息”加到类和属性名中。

（4）因为类的属性是“类的”属性，所以，给属性前面加上类的名称。

（5）因为关联也是属性的一种，只不过类型是另一个类，所以，每个类为关联加一个属性。

（6）因为每个对象都有标识，每个对象都有状态，所以，给每个类加上ID和状态属性。

（关联、状态等相关知识，后文讲述。）

演变过程如图8-65。

图8-65 废话刷工作量的过程

类图上的字从最开始图8-65顶部图形的28字增加到底部图形的135字，但没有增加任何有价值的信息。

********************

“信息”、“数据”等也不是不可以作为类的名称。如果系统关注的焦点是"信息处理"，处理的信息是什么内容无所谓，"信息"、"数据"也可以作为类的名称，但这个时候就不再有"人员"了，它们不在一个抽象级别。类图可能如图8-66。

图8-66 "信息"作为一个类的名称