Introduction to Software Engineering（TE）

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 圖格式
是否強調結構化	? 強調結構化程序控制流程	? 強調結構化三結構原則