当前位置：首页 > news >正文

Introduction to Software Engineering（TE）

news 2025/6/26 20:02:08

Program Design Language

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

PDL 的同类（或相关替代）

名称	简介	是否代码结构化
流程图 (Flowchart)	用图形方式描述处理逻辑	✅
伪代码 (Pseudo-code)	通用术语，PDL就是一种伪代码形式	✅
UML 活动图	建模工具中的一种行为建模方式，用于描述过程流程	✅
Nassi-Shneiderman图	结构化图形流程图（无分支线），适用于结构化编程表示	✅
结构化英语	类似自然语言的方式，但带有结构化控制词（如 IF-THEN）	✅

SC 图（Structure Chart，结构图）

是结构化程序设计中用于承上启下的工具。
位于概要设计和详细设计的衔接位置。
主要用于：
- 表示模块之间的调用关系
- 表达系统的模块分解层次结构
- 指明模块之间数据流或控制流的方向

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

DFD 图（数据流图）

用于需求分析阶段
表示数据在系统中的流动和处理过程
不是用来连接设计阶段的工具

PAD 图（Problem Analysis Diagram）

又称“问题分析图”或“过程设计图”
属于详细设计阶段的工具
用于描述单个模块内部的具体实现逻辑
它是SC 图的下级实现图，并不用于“衔接”

程序流程图（Flowchart）

一种早期的通用图形表示法
表达过程控制逻辑，但缺乏模块化、结构化设计特征
不适合用于大规模系统设计的层级表达

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

阶段	图形工具	中文名称	作用说明
1. 需求分析	DFD 图	数据流图	分析系统做什么，表达数据如何流动
2. 概要设计	SC 图	结构图	把系统分成多个模块，表达模块间调用结构
3. 详细设计	PAD 图	过程设计图	描述某个模块“内部怎么做”
4. 编码辅助	流程图	程序流程图	可选工具，适合小模块的过程控制逻辑表达

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

耦合类型	英文名	简要说明	强弱级别
内容耦合	Content Coupling	一个模块直接修改/访问另一个模块内部数据或逻辑	❌ 最强（最差）
控制耦合	Control Coupling	一个模块控制另一个模块的执行逻辑（如传入标志位）	较强
公共耦合	Common Coupling	多个模块共享全局变量	中等
数据耦合	Data Coupling	模块间仅通过参数传递必要数据，不含控制信息或全局变量	✅ 最弱（最好）

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

选项	图形工具名称	英文缩写	用途说明
A	数据流图	DFD (Data Flow Diagram)	用于需求分析阶段，描述数据流转而非结构
B	过程设计图	PAD (Problem Analysis Diagram)	用于详细设计阶段，描述模块内部逻辑
✅ C	结构图	SC (Structure Chart)	✅ 用于描述软件模块结构和调用关系
D	实体-联系图	ER (Entity-Relationship Diagram)	用于数据库设计，描述实体与关系结构

序号	中文名称	英文缩写	简述
①	内容耦合	Content Coupling	直接访问另一个模块内部数据或控制其逻辑
②	公共耦合	Common Coupling	多模块共享全局变量
③	控制耦合	Control Coupling	一个模块控制另一个模块的执行逻辑（如传标志）
④	标记耦合	Stamp Coupling	传递的数据结构包含对方不需要的字段
⑤	数据耦合	Data Coupling	只通过必要数据参数进行交互
⑥	非直接耦合	Non-direct Coupling（非标准）	基本上无任何调用关系、数据关系
⑦	无耦合	No Coupling	完全独立

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

“问题域对象”即系统要解决的问题空间中真实存在的实体（例如：图书馆系统中的“图书”、“借阅者”、“借书记录”）。
识别这些对象，是将现实问题映射到程序世界的第一步。

概念	英文缩写/词组	说明
面向对象分析	OOA (Object-Oriented Analysis)	识别对象与需求建模
问题域对象	Problem Domain Objects	分析对象模型的核心内容
面向对象设计	OOD (Object-Oriented Design)	描述对象结构和交互（设计层面）

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

模型类型	说明	代表图形工具/建模图
对象模型	表示系统中涉及的类、对象、属性、操作、关系等结构	类图（Class Diagram）
功能模型	描述系统要完成的功能与输入输出之间的变换关系	数据流图（DFD）、用例图（Use Case）
动态模型	表示对象如何随时间变化、如何响应事件、状态如何迁移等	状态图、时序图（Statechart / Sequence）

DFD

Data Flow Diagram

功能建模工具之一

UML

Unified Modeling Language

通用建模语言（统一建模）

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

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

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

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

阶段	主要活动	常用建模工具/方法
① 可行性研究	立项、成本估算、风险分析	无建模，主要是文档+表格
② 需求分析	明确系统做什么	DFD（数据流图）、ER图、用例图
③ 概要设计	系统如何分模块	SC图（结构图）、模块图
④ 详细设计	每个模块怎么实现	PAD图、伪代码、类图、状态图等
⑤ 编码实现	编写源代码	编程语言 + 编码规范
⑥ 测试验证	检查是否满足需求	单元测试、集成测试、验收测试等
⑦ 部署运维	上线并维护	日志监控、用户反馈系统

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

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

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

步骤	活动内容	对应模型/图形工具
1. 领域建模	抽象出问题空间的对象和关系	类图、对象图
2. 用例建模	从用户视角分析功能需求	用例图（Use Case Diagram）
3. 静态建模	描述系统结构（类、关系、继承等）	类图、包图等
4. 动态建模	描述行为随时间变化（状态/交互）	状态图、时序图
5. 交互建模	表现对象间如何协作完成用例	通信图、协作图
6. 实现建模	映射到代码结构	部署图、组件图

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

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

**敏捷开发（Agile）**不强调一次性完成建模或设计，而是：
- 快速识别最关键用例/对象
- 快速建立最小可行产品（MVP）
- 不断从用户反馈中修正模型与代码
- 建模工具以轻量、可沟通为主，比如手绘用例图或白板类图

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

方法模型	活动顺序是否固定	是否强调建模	特点说明
瀑布模型	✅ 固定顺序	✅ 严格建模	适合需求稳定、流程清晰的项目
统一过程（RUP）	✅ 分阶段进行	✅ 全建模	面向对象项目的标准流程，强调文档与模型
敏捷开发	❌ 不固定，可回退	⭕ 建模灵活	强调快速交付，建模最小化
原型法	❌ 反复迭代验证	⭕ 部分建模	快速做出初版原型，边试边改

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

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

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

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

定义可验证的软件需求（✅）
→ 让开发人员和客户都能理解并确认需求是否明确。
描述客户需求（✅）
→ 用结构化方式表达“系统应该做什么”，便于交流。
为设计建立逻辑基础（✅）
→ 分析建模输出的模型是设计阶段输入的依据。
强调系统功能而非实现方式（✅）
→ 分析阶段不解决“怎么做”，而是“做什么”。

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

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

分析建模不提供“解决方案”，它提供“问题的结构化描述”。
它不关心“简单”或“复杂”，也不会直接提出“怎么解决”。

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

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

每个加工必须有：
- 至少一个输入数据流（即有“数据进来”）
- 至少一个输出数据流（即有“数据出去”）

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

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

比如：

登陆验证功能（一个过程）
商品列表加载（一个过程）
订单提交（另一个过程）

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

❓为什么叫“实体”？

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

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

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

比如：

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

用户身份
商品库存
支付接口
收货地址

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

检查库存
校验用户
创建订单
发起支付

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

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

比如：

登录模块提供一个 verifyLogin() 接口
你传入用户名和密码，它返回结果
但你不知道它内部是数据库查？Redis查？有没有日志记录？你都不知道

这就叫信息隐藏。

🔁 好处：

减少模块间耦合
方便后期维护、替换、优化

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

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

内聚类型	中文含义	是否强内聚	举个例子
顺序内聚	输出传给下一个输入	✅ 中等偏强	表单处理、流水线式数据加工
过程内聚	按顺序执行，但数据无依赖	⚠ 偏弱	打印、保存、退出一起做，但互不相关
功能内聚	所有操作围绕一个明确目标	✅ 最强	登录模块、支付模块
偶然内聚（最差）	几个功能硬塞一起，没啥关系	❌ 最弱	临时写了好几个功能堆一个函数里

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

比如：

一个模块负责处理学生成绩，它里面有：
- 统计总分
- 统计平均分
- 找出最高分

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

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

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

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

举个例子：

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

内聚等级（由弱到强）	特征
偶然 → 逻辑 → 时间 → 顺序 → 通信 → 功能
功能内聚 ✅	最纯粹、最整洁的单一目标模块

因为：

模块结构清晰
只处理一件事
可测试性、可维护性最好

为什么它“耦合最弱”？

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

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

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

类型	定义说明	内聚强度	为什么强或弱（关键点）
顺序内聚	一个模块中多个功能前后相连，后一步依赖前一步的输出	✅ 中等	有数据依赖，但每一步的目标不同，仍然偏“串联”
通信内聚	模块内所有功能围绕同一个数据结构进行输入或输出操作，功能彼此平行但相关	✅ 稍强	虽然功能不同，但关注点统一、数据一致性强

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

阶段	英文名称	关注点	主要产出	举例
概念设计	Conceptual Design	现实世界中有哪些实体、属性、关系	概念模型（如ER图）	学生、课程、选课三者的联系
逻辑设计	Logical Design	数据库逻辑结构，如何转化为表结构	逻辑模式（如关系模型）	学生表、课程表、选课表，以及字段设计
存储设计	Physical Design	如何在磁盘上高效存储和访问数据	索引、分区、文件结构	给“学生ID”加索引，选择聚簇还是非聚簇

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

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

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

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

概念	英文	含义
扇出	Fan-out	一个模块调用的下级模块个数（你派出多少个子任务）
扇入	Fan-in	一个模块被上级模块调用的次数/个数（你被多少人当作工具调用）

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

顶层模块（像总指挥）负责组织调度，所以扇出高：它要调用很多子模块
中间层模块起到桥梁作用，不要太复杂，所以扇出较低：尽量不要它再派任务
底层模块是“工具模块”，比如“计算平均数”“输出到文件”等，所以扇入高：大家都来用它，它自己不再调别人

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）

定义：模块中所有操作必须在相同时间点执行，例如程序启动时或关闭时。
特征：
- 功能有一定时间相关性
- 通常见于“初始化模块”“退出清理模块”
例子：
```
系统启动模块：
- 初始化数据库连接
- 加载配置文件
- 清屏
```
👉 它们虽然做的事情不同，但都必须在“启动时”发生。
✅ 比前两个好一点，但仍然功能不集中

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

项目	软件结构图（Software Structure Chart, SC 图）	数据图（Data Flow Diagram, DFD）
中文叫法	软件结构图 / 程序结构图	数据流图
核心关注点	模块层级结构与调用关系（“怎么做”）	数据处理流程与逻辑功能（“做什么”）
表达的是	模块的控制层次、调用顺序、扇入扇出	输入/输出数据流、加工过程、外部实体、存储
使用阶段	结构设计阶段（软件设计中期）	需求分析阶段（软件设计前期）
是否体现数据流动	❌ 不强调（偏控制流）	✅ 强调数据流转与变换
主要用途	为程序模块划分和代码结构做准备	理解业务流程，定义功能范围

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

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

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

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

✅ 说明：

概要设计/高层设计：重“结构关系”
详细设计/低层设计：重“逻辑实现”

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

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

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

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

它重点描述：

系统是由哪些模块构成的（模块划分）
各模块之间是如何调用/控制的（控制关系）
调用时是否有参数/数据传递（数据传递）

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

选项	是否主要组成	解释
A. 模块	✅ 是	每个框框都是一个模块，基本单元
B. 模块间传递的数据	✅ 是	通常用带箭头的线标注参数传递
C. 模块内部数据	❌ 否	❗结构图不画模块内部细节，只画模块之间的关系
D. 模块的控制关系	✅ 是	用线连接上层模块与下层被调用模块，表示控制关系

结构图中的常见符号

矩形框：表示一个模块
箭头线：表示控制流（调用关系）
空心/实心圆圈、线段注释：表示传递数据、判断点（有时）

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

结构图（Structure Chart）
搭配内聚、耦合分析
强调模块化、层次化、信息隐藏

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

选项	原因
A. 测试用例设计	属于软件测试阶段，与结构化设计无关
B. 软件概要设计	使用的是结构化分析方法（如 DFD），不是结构化“设计”
C. 程序设计	太宽泛，可能包括编码，不是结构化设计特指的阶段
✅ D. 软件详细设计	✔ 正确，结构化设计就是这个阶段用的核心方法

特征	顺序内聚（Sequential Cohesion）	过程内聚（Procedural Cohesion）
是否有数据依赖（输入/输出）	✅ 有：一个功能的输出是下一个的输入	❌ 无：各功能顺序执行但不共享数据
功能之间的逻辑关系	线性传递，像流水线	顺序存在，但无数据耦合，像脚本任务清单
举例	从输入读文件 → 处理数据 → 输出结果	打开文件 → 打印标题 → 关闭文件
内聚强度（相对）	✅ 更强	较弱
图示	`A ➝ B ➝ C`（A输出→B输入）	`A; B; C`（只是顺序执行）

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

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

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

维度	概要设计（High-Level Design）	详细设计（Low-Level Design）
方法	常用结构化分析方法（Structured Analysis）	使用结构化设计方法（Structured Design）
工具	DFD（数据流图）、数据字典、实体关系图	Structure Chart（结构图）、模块接口表、伪代码
关注点	系统分为哪些大模块、数据如何在模块之间流动	每个模块内部怎么写、控制流程如何安排、数据如何传入传出
抽象程度	比较“粗”，确定功能块和大体结构	更“细”，接近代码实现
输出物	模块划分文档、系统流程图	模块接口文档、结构图、控制流程说明

结构化分析 → 用在概要设计 → 画 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: booleanBEGINIF n <= 1 THENRETURN falseFOR i FROM 2 TO sqrt(n) DOIF n MOD i = 0 THENRETURN falseRETURN true
END

你可以看到，它：

用的是伪英语风格的关键字（IF, RETURN, FOR）
不涉及任何具体语言语法（比如没有 C 的 {}，也没有 Python 的缩进规则）
逻辑清晰、便于沟通

HIPO（Hierarchy plus Input-Process-Output） 是一种结构化文档工具，用于表示模块之间的层次关系与输入输出。
PDL（Program Design Language） 是结构化伪码，用于说明模块内部处理逻辑。

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

结构化设计（Structured Design） 是详细设计阶段的核心方法，强调模块化、层次化、信息隐藏、内聚与耦合控制。
它配合结构图、PDL、模块说明等工具，详细描述每个模块的功能与接口。

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

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

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

工具名称	作用	是否图形化
PDL（程序设计语言）	用“伪代码”描述模块内部逻辑，接近真实程序结构	否（文字描述）
PAD 图（Problem Analysis Diagram）	用顺序/选择/循环块表示流程，强调结构清晰	✅ 是
流程图（Flowchart）	展示操作的顺序、分支与循环，容易直观表现控制逻辑	✅ 是
Nassi-Shneiderman 图	结构化流程图，每个控制结构一个矩形块，强制结构化	✅ 是
IPO 图（输入-处理-输出）	描述模块的数据输入、处理过程和输出结果	✅ 是
模块接口说明表	列清楚每个模块的参数、输入输出、调用方式	否（表格描述）

设计问题	详细设计工具如何帮助解决
模块怎么实现？	用 PDL 或 PAD 图明确每一步的处理逻辑
数据从哪里来，怎么处理？	用 IPO 图来分析输入 → 处理 → 输出关系
模块内部的控制逻辑是否清晰？	用 PAD、流程图或 Nassi 图结构化呈现
是否容易转化为代码？	PDL 是写代码前的“半成品”逻辑框架

对比维度	Jackson 方法（JSP）	PAD 图（结构化图）
所属阶段	软件详细设计（过程设计）	软件详细设计（过程设计）
表达方式	以“输入数据结构”为出发点，展开控制结构	以“控制结构三要素”为核心（顺序/选择/循环）
核心思想	程序结构应映射输入数据结构	控制逻辑结构化（结构程序设计三结构）
应用场景	文件处理、数据顺序结构强的问题	任何通用的程序模块逻辑设计
是否图形化	是，有自己的“Jackson 图”	是，使用专门的 PAD 图格式
是否强调结构化	✅ 强调结构化程序控制流程	✅ 强调结构化三结构原则