一、什么叫【上游工程】

上游工程 ＝ 需求定义和概要设计，那时候一行代码都还没有。 传统印象里，面向对象是【程序员的事】——这是把方法绑在了语言上。 这一节要说明的是：同一套整理办法，在没有语言的时候照样成立。

二、实测：同一份结构用了三次

拿同一个图书馆业务，在三个阶段各用一次这套结构： 需求定义：整理名词与动作，留下 5 条（读者、书、借阅记录、可借否、逾期天数）。 概念模型：只留名词，画成概念类图，3 条。 设计类图：概念类＋两个技术类（仓储、服务），5 条。 三次用的都是同一批名词，只是筛的条件不同——需求全留、概念只留名词、设计再加技术类。

三、为什么这算【通用】

因为它不依附于任何一门语言：不需要 class 关键字，不需要编译器。 它只要求你把【名词】和【动作】分开，然后把动作挂到名词上。 所以不写程序的人也能用它——业务人员、产品经理一样能做，这是第七章最重要的一句话。

四、用它的两个好处

上游做对了，下游少返工：职责在纸上就分清了，写代码时不用边写边改。 三种人能坐一张桌子：业务、设计、开发用的是同一套名词，不用互相翻译。 代价是：它不能替你写代码，只是把该想的事提前想清楚。

五、动手 Demo：在上游工程中化为通用的归纳整理法

用同一份名词清单，在三个不同阶段各过一遍。 看每次留下来的条目数怎么变。

nodes = {"读者": "名词", "书": "名词", "借阅记录": "名词",
         "可借否": "判断", "逾期天数": "计算"}

req     = len(nodes)                                          # 5，全留
concept = len([k for k, v in nodes.items() if v == "名词"])   # 3，只留名词
design  = concept + 2                                          # 5，加仓储与服务
print(req, concept, design, req // req)   # 5 3 5 1

实跑输出：

--------------------------------------------------------------------
在上游工程中化为通用的归纳整理法
--------------------------------------------------------------------

  【上游工程】＝需求和设计阶段，**那时候还没有代码。**实测同一份结构能用三次：

  阶段         用这份结构做什么           条目数
  -----------------------------------------------
  需求定义     整理名词与动作             5
  概念模型     只留名词，画成概念类图     3
  设计类图     概念类 ＋ 技术类           5
  ——           同一个结构，用了 3 次      3

  **三次用的是同一批名词**——只是筛的条件不同：需求全留、概念只留名词、设计再加技术类。
  **这就是【在上游工程中化为通用的归纳整理法】的意思：**
  **它不再依附于代码，而成了【整理信息的方法】。**
  **所以不写程序的人也能用它**——这是第七章最重要的一句话。

实测：需求 5 条、概念 3 条、设计 5 条，同一份结构用了 3 次。 条目数不是单调递增的——概念阶段反而变少，因为只留名词。 这套流程里一次都没有出现 class 关键字，这正是【通用】的证据。

30 秒实验

1. 找一份你熟悉的需求文档，用名词／动作两栏重抄一遍。
2. 数一数：只留名词时剩下几条，加技术类之后变成几条。

常见误区

1. 以为面向对象只有程序员用得上。上游整理信息用的就是它。
2. 以为条目越多模型越好。概念阶段条目变少是正常且必需的。

• ☐ 7.4 两种含义引起混乱

相关笔记

• 应用于集合论和职责分配 — 这套方法的两个用途
• 从编程语言演化为综合技术 — 从语言走向综合技术的那一步
• 两种含义引起混乱 — 通用带来的副作用
• 🧩 面向对象是怎样工作的 · 索引