Introduction to Software Engineering（TE）

Program Design Language

也称为：伪代码语言（Pseudo-code Language）

PDL 的同类（或相关替代）

SC 图（Structure Chart，结构图）

• 是结构化程序设计中用于承上启下的工具。

• 位于概要设计和详细设计的衔接位置。

• 主要用于：

  • 表示模块之间的调用关系

  • 表达系统的模块分解层次结构

  • 指明模块之间数据流或控制流的方向

所以，SC 图是概要设计的输出，同时也是详细设计的输入依据，用于指导每个模块内部的 PAD 图或伪代码设计。

DFD 图（数据流图）

• 用于需求分析阶段

• 表示数据在系统中的流动和处理过程

• 不是用来连接设计阶段的工具

PAD 图（Problem Analysis Diagram）

• 又称“问题分析图”或“过程设计图”

• 属于详细设计阶段的工具

• 用于描述单个模块内部的具体实现逻辑

• 它是SC 图的下级实现图，并不用于“衔接”

程序流程图（Flowchart）

• 一种早期的通用图形表示法

• 表达过程控制逻辑，但缺乏模块化、结构化设计特征

• 不适合用于大规模系统设计的层级表达

按照软件开发阶段的逻辑顺序如下：

常见耦合类型（由强到弱）

“软件结构使用的图形工具

📌 注：不同教材中“非直接耦合”有时不列入七种之一，而是作为“最低耦合”或“理想情况”补充出现。

• “问题域对象”即系统要解决的问题空间中真实存在的实体（例如：图书馆系统中的“图书”、“借阅者”、“借书记录”）。

• 识别这些对象，是将现实问题映射到程序世界的第一步。

面向对象分析过程中常见的三类模型：

“建模、分析这些活动有没有标准的先后顺序，还是说存在多种流程方法？”

✅ 既有经典标准顺序（常见于传统模型），也存在多种变体流程（如敏捷、迭代、原型方法）。
也就是说，不同的软件开发方法论中，这些活动的顺序可能固定、交错、或者反复回溯。

标准的“瀑布模型”顺序（最典型的线性流程）

这种是传统软件工程中最明确的阶段性流程：

📌 在这个模型中，每一步都严格在前一步完成后进行，所以“建模”通常穿插在第 2–4 阶段。

面向对象开发模型中的顺序（适配 UML 流程）

UML 方法论中推荐的是一种“逐步细化、结构清晰”的过程，顺序如下：

📌 这些建模活动可以并行推进，但通常建议先有静态结构，再逐步补充行为与交互。

敏捷开发中的建模顺序：没有固定顺序，更强调迭代

• **敏捷开发（Agile）**不强调一次性完成建模或设计，而是：

  • 快速识别最关键用例/对象

  • 快速建立最小可行产品（MVP）

  • 不断从用户反馈中修正模型与代码

  • 建模工具以轻量、可沟通为主，比如手绘用例图或白板类图

常见的模型构建流程对比总结

先明确什么是分析建模（Analysis Modeling）？

分析建模是软件开发中需求分析阶段的重要组成部分，其核心目的是：

把模糊的用户需求，结构化、形式化地表达出来，为后续设计和实现做好准备。

标准分析建模的四个主要目的：

1. 定义可验证的软件需求（✅）
   → 让开发人员和客户都能理解并确认需求是否明确。

2. 描述客户需求（✅）
   → 用结构化方式表达“系统应该做什么”，便于交流。

3. 为设计建立逻辑基础（✅）
   → 分析建模输出的模型是设计阶段输入的依据。

4. 强调系统功能而非实现方式（✅）
   → 分析阶段不解决“怎么做”，而是“做什么”。

开发一个简单的问题解决方案

这是设计阶段或原型阶段的目标，而不是分析建模的目标。

• 分析建模不提供“解决方案”，它提供“问题的结构化描述”。

• 它不关心“简单”或“复杂”，也不会直接提出“怎么解决”。

DFD 中的“加工”（Process）是指对数据进行转换、处理的操作，图中用一个圆圈或椭圆表示。

按照数据流图的定义规范：

• 每个加工必须有：

  • 至少一个输入数据流（即有“数据进来”）

  • 至少一个输出数据流（即有“数据出去”）

✅ 因为加工是对输入数据的处理 → 没有输入就无数据可处理；没有输出就无结果流出

“过程实体”= 软件中独立、可识别、可操作的逻辑过程或功能单元。

比如：

• 登陆验证功能（一个过程）

• 商品列表加载（一个过程）

• 订单提交（另一个过程）

每个功能，都可以抽象为一个过程实体（Process Entity）。它不是“变量”“类”“对象”，而是某个清晰独立的过程动作/功能逻辑块。

❓为什么叫“实体”？

是因为我们不止是说“功能”这个抽象概念，而是说“这个功能在系统中要成为一个明确的、单独的、可调度的存在”，就像对象、模块一样——所以叫实体。

抽象（Abstraction）是软件设计的第一步：

它的作用就是：从复杂的现实中，提炼出清晰可控的逻辑单位。

比如：

现实中“用户下单”这个行为很复杂，要处理：

• 用户身份

• 商品库存

• 支付接口

• 收货地址

但我们可以通过抽象，把它整理成几个清晰的过程实体：

1. 检查库存

2. 校验用户

3. 创建订单

4. 发起支付

这些就是“通过抽象得出的过程实体”。

信息隐藏（Information Hiding）就是：每个模块只暴露必要的接口，内部怎么做你别管。

比如：

• 登录模块提供一个 verifyLogin() 接口

• 你传入用户名和密码，它返回结果

• 但你不知道它内部是数据库查？Redis查？有没有日志记录？你都不知道

这就叫信息隐藏。

🔁 好处：

• 减少模块间耦合

• 方便后期维护、替换、优化

模块内部有好几个小功能（步骤），它们按顺序执行，而且后面的功能直接吃前面的输出结果当“输入”用。

就像接力赛跑，第一棒跑完把接力棒交给第二棒，第二棒才能跑。

通信内聚指：一个模块中各个处理步骤虽然功能不同，但它们都围绕“相同的数据”在操作。

比如：

• 一个模块负责处理学生成绩，它里面有：

  • 统计总分

  • 统计平均分

  • 找出最高分

虽然是三个不同的小功能，但它们都在处理同一个数据结构（如成绩数组），这就叫通信内聚。

因为这些功能之间的共同点不是任务顺序，也不是功能目标，而是它们都依赖于“同一份信息”，所以也叫信息内聚（Informational Cohesion）。

什么是“功能内聚（Functional Cohesion）”？

是指一个模块里的所有操作、数据、流程，都只为完成一项明确的功能目标而存在，且每一步都是不可或缺的。

举个例子：

• 登录模块：校验用户名 → 校验密码 → 返回结果
  每一部分都是为了“完成登录”这个目标，且缺一不可。

因为：

• 模块结构清晰

• 只处理一件事

• 可测试性、可维护性最好

为什么它“耦合最弱”？

因为它自己就能独立完成一项功能，不依赖其他模块太多内部信息或控制信号，所以与其他模块的连接是最少的、最松的。

耦合越弱，模块之间越独立，改一个不影响另一个，系统更稳定。

在模块内聚（Cohesion）的标准分级中，顺序内聚确实比通信内聚要弱。这不是拍脑袋定的，而是从模块的独立性与关注焦点的集中程度来判断的。

数据库的设计指数据存储文件的设计，主要进行的设计方面有：
（ 概念设计 ）、（ 逻辑设计 ）、（ 存储设计 ）

变换型：
输入 → 处理A → 处理B → 处理C → 输出  
（线性）

事务型：
         → 子流程A →  
输入 → 判断 → 子流程B → 输出  
         → 子流程C →
（分支）
 

变换型：一条线；事务型：分支选。
一个是顺序变形流程，一个是按条件选路线。

什么是“扇出”和“扇入”？（核心术语）

📌 它们都是衡量模块结构关系的指标，越合理，结构越清晰、系统越好维护。

• 顶层模块（像总指挥）负责组织调度，所以扇出高：它要调用很多子模块

• 中间层模块起到桥梁作用，不要太复杂，所以扇出较低：尽量不要它再派任务

• 底层模块是“工具模块”，比如“计算平均数”“输出到文件”等，所以扇入高：大家都来用它，它自己不再调别人

         A（顶层，扇出=3）
        / | \
       B  C  D（中层，扇出=1）
       |     |
       E     E（底层，扇入=2）
 

• 顶层高扇出：利于集中控制、统一分派任务

• 中层低扇出：避免中间模块过于复杂，降低耦合

• 底层高扇入：让底层模块复用率高、功能稳定

偶然内聚（Coincidental Cohesion）——最差的一种

• 定义：模块中各功能毫无关系，只是“碰巧”被放在一起。

• 特征：

  • 功能不相关

  • 可能是写代码时随手加进来的

• 例子：

  一个模块里：
  - 显示欢迎界面
  - 打印用户日志
  - 初始化一个数组
  

  👉 看起来完全是乱搭在一起，根本没有逻辑关系。

• ❌ 缺点：

  • 难以维护，改一个容易影响无关的地方

  • 不能被复用

逻辑内聚（Logical Cohesion）

• 定义：模块中有多个功能，它们属于同一类逻辑动作，但具体做哪一个要靠传入的参数来决定。

• 特征：

  • 属于“同类任务”，如：输入处理、输出处理、错误处理

  • 通过参数控制执行逻辑

• 例子：

  void handleIO(int mode) {
      if (mode == 0) readFile();
      else if (mode == 1) writeFile();
      else if (mode == 2) deleteFile();
  }
  

  👉 虽然都跟“文件操作”相关，但通过 mode 控制行为。

• ⚠️ 问题：

  • 参数驱动逻辑，结构不清晰

  • 日后新增功能要频繁改条件判断

时间内聚（Temporal Cohesion）

• 定义：模块中所有操作必须在相同时间点执行，例如程序启动时或关闭时。

• 特征：

  • 功能有一定时间相关性

  • 通常见于“初始化模块”“退出清理模块”

• 例子：

  系统启动模块：
  - 初始化数据库连接
  - 加载配置文件
  - 清屏

  👉 它们虽然做的事情不同，但都必须在“启动时”发生。

• ✅ 比前两个好一点，但仍然功能不集中

偶然最差纯拼凑，逻辑靠参选操作，时间同时起步走。

需求分析 → 数据流图（DFD） → 功能模块识别 → 软件结构图（SC图） → 详细设计 → 编码
DFD 是“需求建模工具”，分析业务流程和数据流动

SC 图是“结构设计工具”，组织模块结构和调用层次

👉 数据图帮助我们确定有哪些功能，
👉 结构图帮助我们安排这些功能如何被实现、由谁来做

→ 需求分析（确定“做什么”）
  ↓
→ 概要设计 / 高层设计（模块划分 + 架构图）
  ↓
→ 详细设计（写模块的“内部结构”）
  ↓
→ 编码实现（根据详细设计写代码）
  ↓
→ 测试、部署、维护

✅ 说明：

• 概要设计/高层设计：重“结构关系”

• 详细设计/低层设计：重“逻辑实现”

什么是结构图（Structure Chart，SC 图）？

结构图是软件结构设计阶段最常用的一种图形工具，用于表示：

模块之间的控制关系与数据传递关系。

它是从数据流图（DFD）演化而来，是在“概要设计”中用于指导模块实现的图示。

它重点描述：

• 系统是由哪些模块构成的（模块划分）

• 各模块之间是如何调用/控制的（控制关系）

• 调用时是否有参数/数据传递（数据传递）

题目：结构图中，不是其主要成分的是（ C ）。

结构图中的常见符号

• 矩形框：表示一个模块

• 箭头线：表示控制流（调用关系）

• 空心/实心圆圈、线段注释：表示传递数据、判断点（有时）

结构化设计是一种从数据流图出发，把逻辑功能模块化、层次化的方法。它的核心工具是：

• 结构图（Structure Chart）

• 搭配内聚、耦合分析

• 强调模块化、层次化、信息隐藏

❌ 对比其他选项为何错误：

偶然 < 逻辑 < 时间 < 过程 < 顺序 < 通信 < 功能

结构化设计方法主要用于：
👉 详细设计阶段（Low-Level Design）

为什么不是“概要设计”阶段？

• 结构化分析 → 用在概要设计 → 画 DFD

• 结构化设计 → 用在详细设计 → 画 Structure Chart（结构图）

SP（Structured Programming）结构化程序设计方法，是一种编写清晰、易读、易维护程序的编程规范与思想。它强调：

• 只使用顺序、选择、循环三种基本控制结构（避免 goto）

• 程序可以像搭积木一样由这些结构组合构建

• 每个模块只完成一个功能，并严格限制内部结构

✅ 举个简单例子说明 SP 风格：

void printPositive(int n) {
    if (n > 0) {
        printf("Positive number");
    } else {
        printf("Non-positive number");
    }
}
这个函数没有用到 goto，而是使用选择结构（if-else），就是结构化程序设计的一种体现。

PDL 是用于在详细设计阶段描述模块内部逻辑的“伪代码形式”的结构化语言，帮助程序员将自然语言思路过渡到真正的代码实现。

PDL 的主要用途：

• 描述一个模块的算法流程

• 明确模块的输入、输出、控制结构

• 是从结构化设计过渡到编码的中间过渡文本

• 人看得懂，但机器不能直接执行

MODULE isPrime
INPUT: integer n
OUTPUT: boolean

BEGIN
    IF n <= 1 THEN
        RETURN false
    FOR i FROM 2 TO sqrt(n) DO
        IF n MOD i = 0 THEN
            RETURN false
    RETURN true
END

你可以看到，它：

• 用的是伪英语风格的关键字（IF, RETURN, FOR）

• 不涉及任何具体语言语法（比如没有 C 的 {}，也没有 Python 的缩进规则）

• 逻辑清晰、便于沟通

• HIPO（Hierarchy plus Input-Process-Output） 是一种结构化文档工具，用于表示模块之间的层次关系与输入输出。

• PDL（Program Design Language） 是结构化伪码，用于说明模块内部处理逻辑。

这两个都是详细设计阶段常用的规格说明手段。

• 结构化设计（Structured Design） 是详细设计阶段的核心方法，强调模块化、层次化、信息隐藏、内聚与耦合控制。

• 它配合结构图、PDL、模块说明等工具，详细描述每个模块的功能与接口。

PDL 并不是代码注释，而是设计阶段使用的伪代码说明语言，它通常作为设计文档的一部分存在，而不是直接嵌入代码中当注释使用。
而且，即便某些公司允许在注释中嵌入 PDL 描述，也不是 PDL 的标准定义内容，因此这个说法不准确。

流程图并不强调“从抽象到具体”的逐步求精过程，反而常常直接给出完整实现逻辑，不具备分层递进的表达能力。这正是 PAD 图胜过流程图的地方。

需求分析 → 概要设计 → ✅ 详细设计 → 编码 → 测试 → 运维
                         ↑
              这一步中使用详细设计工具

✅ 结论：

• 你可以理解为：Jackson 方法和 PAD 是“达到模块内部结构清晰”的两种不同技术路线。

• 就像画图时有铅笔素描法和水彩法，目的都是“表现结构”，但用法和偏好不同。

• 在实际使用中，不同开发组织可能选用其中之一或混合使用。

An excellent course, yet regrettably one that rarely finds its place beyond academia.