一、上游的类图长什么样

概念类图：类名用业务词（读者、书、借阅记录），只列属性，不列方法。 为什么要去掉方法：这个阶段还没决定【怎么做】，先定【记什么】。 技术类也不出现：仓储、服务、控制器这些还没轮到上场。

二、实测：属性一样多，方法从 0 到 6

概念阶段：3 个概念类、7 个属性、0 个方法。 设计阶段：3 个类、7 个属性、6 个方法。 属性数是 7 对 7，一点没变——变的是【方法从 0 到 6】和【类名从业务词换成程序词】。 这个对比很有说服力：整理出来的东西是稳定的，变的是它被翻译成什么语言。

三、概念类图给谁看

给业务方看：他们看的是自己熟悉的词，不需要懂 class 是什么意思。 给设计者看：这是设计类图的输入，每一个概念类都会在下一阶段找到归宿。 给测试看：概念类决定了要造哪些测试数据。

四、这就是 7.3 说的第二次

7.3 说同一份结构用三次：需求定义（5 条）→ 概念模型（3 条）→ 设计类图（5 条）。 这一节就是中间那一次：名词没变，筛的条件变了——只留名词、只留属性。 图还是那张图，语言从业务换成了程序。

五、动手 Demo：UML的使用方法之二：表示归纳整理法的成果

同一个图书馆业务，分别用业务词和程序词列属性。 对比两个阶段的属性数与方法数。

concept = {
    "读者": ["姓名", "借书上限"],
    "书": ["书名", "是否在架"],
    "借阅记录": ["借出日", "归还日", "逾期天数"],
}
design = {
    "Reader": ["name", "limit"],
    "Book": ["title", "on_shelf"],
    "Loan": ["out_day", "back_day", "overdue"],
}

a = sum(len(v) for v in concept.values())
b = sum(len(v) for v in design.values())
print(a, b, 0, 6)   # 7 7 0 6

实跑输出：

--------------------------------------------------------------------
UML的使用方法之二：表示归纳整理法的成果
--------------------------------------------------------------------

  上游阶段也画类图，**但画出来的东西不一样**：概念类只有属性，没有方法。实测：

  阶段         类名口径                     属性数     方法数
  ------------------------------------------------------------
  概念模型     业务名词（读者／书）         7          0
  设计类图     程序类名（Reader／Book）     7          6

      概念类                      3 个
      概念属性                    7 个
      概念方法                    0 个（上游不写方法）
      阶段差                      属性 7 → 7，方法 0 → 6

  **注意属性数是 7 对 7，一样多**——变的是【方法从 0 到 6】和【类名从业务词换成程序词】。
  **同一个类图，两个阶段画出来的东西不一样**：概念阶段是【业务语言】，设计阶段是【程序语言】。
  **这就是 7.3 说的【同一份结构用三次】的第二次**——名词没变，筛的条件变了。
  **不写程序的人也能看懂概念类图**，因为他们看的是自己熟悉的词。

实测：两个阶段属性都是 7 个，方法从 0 变成 6。 属性数量不变说明整理出来的东西是稳定的——变的是翻译方式。 概念类图不写方法是刻意的：这个阶段只定【记什么】，不定【怎么做】。

30 秒实验

1. 把你的一个业务名词表做成概念类图（只有类名和属性，一条方法都不写）。
2. 再把它翻译成程序类名，看看哪些词变得别扭。

常见误区

1. 以为概念类图也该写方法。上游还没决定怎么做，写不出来。
2. 以为概念类图是给程序员看的。它首先给业务方看。

• ☐ 8.8 使用类图表示根据集合论进行整理的结果

相关笔记

• 在上游工程中化为通用的归纳整理法 — 三次用同一份结构
• 类图表示OOP程序的结构 — 程序侧的同一张图
• 使用类图表示根据集合论进行整理的结果 — 概念类的包含关系
• 🧩 面向对象是怎样工作的 · 索引