功能点 → 功能流程 + 算法设计：功能内部怎么执行

功能点回答「软件要提供什么能力」，功能流程回答「这个功能内部一步步怎么执行」，算法设计回答「每一步里具体的计算怎么做」。这一条线：分析功能点，得到功能流程和算法设计。它是四条分析链的第三条，也是最后把「业务」翻译成「程序执行」的一条。

一、功能流程：功能内部的执行步骤

业务流程图是「用户视角」的流程，功能流程图是「程序视角」的流程——一个功能点内部，程序一步步做什么：

1
2
3
功能点：读取进程内存
  ↓ 功能流程（程序内部的执行步骤）
ReadMemory → 检查参数 → 地址转换 → 调用驱动 → 返回数据
1
2
业务流程图（用户视角）：查看进程 → 选择进程 → 打开 → 读取 → 显示
功能流程图（程序视角）：检查句柄 → 地址校验 → 转换地址 → 读取 → 返回

业务流程描述用户的操作，功能流程描述程序的执行——同一件事的两个视角。

二、算法设计：功能流程里的计算

功能流程的每一步，都可能需要具体的计算。算法就是这些计算：

1
2
3
功能流程：ReadMemory → 检查参数 → 地址转换 → 调用驱动 → 返回数据
                                     ↓
算法：地址转换怎么算？（虚拟地址 → 物理地址的换算逻辑）
1
业务流程 → API 接口 → 功能流程 → 算法

以进程管理器为例：

1
2
3
4
5
功能流程：读取进程内存
  步骤 1：校验参数（PID 是否合法）          ← 简单判断
  步骤 2：地址转换（虚拟地址 → 物理地址）    ← 算法
  步骤 3：读取数据                          ← 调用系统接口
  步骤 4：返回                              ← 组织结果

功能流程组织步骤，算法实现步骤里的计算。

三、功能流程和算法的分工

1
2
3
4
5
6
功能流程：步骤的顺序组织（先做什么、后做什么、什么条件下做什么）
算法：    步骤内部的计算逻辑（怎么算）

同一段代码里：
  流程 = 函数体的骨架（分支、循环、调用的顺序）
  算法 = 具体的计算（数学换算、搜索、排序）

这个分工正好对应业务系统的模块结构：

1
2
功能流程 → Service/功能函数（组织业务流程、调用能力）
算法     → Algorithm 层（具体计算）

为什么必须分开？ 功能流程会随业务变化（步骤增删），算法相对稳定（计算逻辑固定）。分开后，改流程不动算法，换算法不动流程——这是「单一职责」在功能层的体现。

四、产物

1
2
3
4
5
6
7
8
功能点设计文档
  ↓
功能流程分析文档（每个功能内部怎么执行）
  ↓
功能流程图 + 算法列表

功能流程图 → 程序执行的骨架（函数体的组织）
算法列表   → 需要实现的算法清单（每个算法用什么形式表达）

算法列表是「算法类型与描述形式」线的输入——步骤型用流程图、数学型用公式、状态型用状态机。

五、和其他线的关系

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
功能点 → 功能流程 ←→ 算法（算法类型与描述形式）
  功能流程拆出的算法列表，是算法线的输入

功能点 → 功能流程 ←→ 业务系统（系统角色）
  功能流程落在 Service/功能函数，算法落在 Algorithm 层

功能点 → 功能流程 ←→ 单一职责
  流程与算法分离 = 职责分离（流程管组织、算法管计算）

功能点 → 功能流程 ←→ 设计表示
  功能流程用流程图表达（步骤顺序类表示）

功能点 → 功能流程 ←→ 七条流/业务流·功能流
  业务流程是业务流，功能流程是功能流——分析侧的两种流程
  对应运行时侧的业务流和功能流

收束

1
2
3
4
5
6
7
8
9
10
11
功能点（软件要提供什么能力）
  ↓
功能流程（功能内部程序一步步怎么执行）
  ↓
算法设计（每一步里具体的计算）

业务流程 → API 接口 → 功能流程 → 算法
  流程组织步骤，算法实现计算
  流程随业务变，算法相对稳定 → 分开设计

产物：功能流程图 + 算法列表

功能点回答「提供什么能力」，功能流程回答「能力内部怎么执行」，算法回答「计算怎么做」——到这里，业务分析链就结束在可实现的单元上。而数据结构不在这条链上，它来自其他设计（见线 04）。