1. D、結構化技術
結構化技術之概念

主要的結構化技術

– 結構化程式設計
– 由上而下發展
– 結構化設計
• 經驗法則、評估準則、文件工具
– 結構化分析
結構化分析與設計做法

系統分析與設計 楊子青 D-1

2. 1. 結構化技術之概念
系統開發模式

– 強調系統開發過程中應有之步驟以及執行
程序
– 不涉及每個步驟可支援的方法或技術
結構化技術 (又稱軟體工程技術)

– 起源於1960年代末期
– 主要強調如何應用一些概念、策略與工具，
以提升系統分析與設計、程式設計與測試之
效率與效能等。
系統分析與設計 楊子青 D-2

3. 2. 主要的結構化技術
結構化程式設計 (Structured Programming)

由上而下發展 (Top-down Development)

結構化設計 (Structured Design)

結構化分析 (Structured Analysis)

系統分析與設計 楊子青 D-3

4. 2.1 結構化程式設計
由Dijkstra (1969)提出

– 消除程式因goto而造成如麵條式的混亂狀態
– 強調任何程式邏輯均可由三種結構組成
• 循序(sequence)：簡單命令式的指令如 COMPUTE,
READ, WRITE 與代數指令如X=Y+Z。
• 選擇(condition)：需做決策時，用 IF-THEN-ELSE 指
令與 CASE 指令。
• 重複(repetition)：當需反覆時，用 DO-WHILE 與
DO-UNTIL 指令。
系統分析與設計 楊子青 D-4

5. 結構化程式之邏輯概念
系統分析與設計 楊子青 D-5

6. 2.2 由上而下發展
起源於1960年代末期

強調把大問題依序分解成具層級結構之小模

組，並由上層模組開始進行程式設計及測試
– 層級化設計
– 延緩考慮細節問題：
包含三個相關但不同方面的「由上而下」：

– 由上而下設計(Top-down Design)
– 由上而下編碼(Top-down Coding)：當高階模組被
設計完成後，就先對高階模組撰寫程式
– 由上而下整合測試 (Top-down Integration Test)
系統分析與設計 楊子青 D-6

7. 由上而下設計
把大而複雜的問題分解成較小且較簡化的問題

，直到原來的問題已可用一些容易且可理解的
小問題組合來代表。例：
– 先將主程式分為A、B、C三個子程式
– 再劃分子程式A為A1與A2，子程式C為C1與C2
Main
Ａ B C
Ａ1 Ａ2 C1 C2
系統分析與設計 楊子青 D-7

8. 由下而上設計
先獨立發展各個細部的子程式X, Y, Z

Ζ
Ｘ Ｙ
再將X, Y, Z組成較高的子程式A1

經過逐次整合成為完整系統

Main
A1 A1 B
Ζ Ζ
Ｘ Ｙ Ｘ Ｙ
系統分析與設計 楊子青 D-8

9. 由上而下整合測試
在低階模組尚未完成程式撰寫前，先行

測試系統的高階模組
– 由頂端模組開始測試，而以虛擬模組
(Dummy Module)暫代下一層未完成的模組
• 系統的錯誤若在上階層，則可及早發現。
• 需要製造虛擬模組。
系統分析與設計 楊子青 D-9

10. 2.3 結構化設計
起源於1960年代末期，其概念先於結構

化分析
– 主要目的：將資訊系統依由上而下發展，並
將程式設計模組化與結構化。
• 決定系統應有哪些模組？
• 模組間以何種相互聯繫才能最有效解決問題？
– 特別強調系統的可維護性
系統分析與設計 楊子青 D-10

11. 模組(Module)
即副程式，為一連串指令的集合，包括：

(1)模組名稱：唯一且應有意義，應能表達模組的功能
(2)輸入：模組被呼叫時，呼叫模組所需輸入的資料
(3)
(3)輸出：模組執行後所產生的輸出結果
(4)處理邏輯：為達成模組功能，模組內所需具備的執
行程序與邏輯。
(5)內部資料：該模組獨自擁有而不與其他模組共用的
資料
系統分析與設計 楊子青 D-11

12. 結構化設計之法則與工具
包括設計經驗法則、評估準則與文件工具等

– 經驗法則
• 模組大小、控制間距、控制範圍
– 評估準則
• 模組內部所做事情的相關程度(內聚力)
• 模組間的相關程度(耦合力)
• 有很好的功能分割
– 文件工具
• 結構圖(Structure Chart)
• HIPO圖 (Hierarchical Input Process Output)
• 模組規格描述、資料字典
系統分析與設計 楊子青 D-12

13. 2.3.1 結構化設計之經驗法則
模組大小

– 基於小模組較大模組容易維護與修改，故結構化設
計較傾向用小模組。
• 一般來說，小模組約包含 200 個以下的程式指令
• 例如，可列印在1～2頁之A4紙內
控制間距

– 一個模組不要同時控制太多即時模組，因為控制太
多模組將不利瞭解與維護。
– 最多不要超過9個(Magic Number 7±2)
控制範圍

– 為縮小影響範圍與控制範圍，當甲模組之行為被乙
模組所影響，則甲模組應從屬於乙模組。
系統分析與設計 楊子青 D-13

14. 2.3.2 結構化設計之評估準則
要達到良好的系統設計與提升模組的品

質，需考慮：
– 模組的內聚力(cohesion)：一個模組內部所做
事情的相關程度。
– 模組間的耦合力(coupling)：一個系統內部各
模組之間的相關程度。
– 其他考慮因素：如功能分割、錯誤訊息等。
系統分析與設計 楊子青 D-14

15. 2.3.2.1 內聚力
衡量模組內部工作相關程度的方法

– 也就是衡量模組完成一件單一、且定義清楚
之工作的程度，可分為七種：
功能內聚力(Functional Cohesion)
•
順序內聚力(Sequential Cohesion)
•
溝通內聚力(Communication Cohesion)
•
程序內聚力(Procedural Cohesion)
•
暫時內聚力(Temporal Cohesion)
•
邏輯內聚力(Logical Cohesion)
•
偶發內聚力(Coincidental Cohesion)
•
系統分析與設計 楊子青 D-15

16. (1) 功能內聚力
一個模組只做一件事情

亦即每個模組僅具有唯一的功能

例如：以下的三個處理均僅針對一件事

，若分別成為一個模組，則具有功能內
聚力
檢查身分證 以異動檔
計算營業稅
號碼正確性 更新庫存主檔
系統分析與設計 楊子青 D-16

17. (2) 順序內聚力
模組內具有多個功能或處理多件事情，

且一項功能的輸出立即成為下一個功能
的輸入、共用相同的資料
圖例：

將計算所得結果
讀取某數值ｘ 計算ｘ之平方
顯示於螢幕上
系統分析與設計 楊子青 D-17

18. (3) 溝通內聚力
模組內具有多個功能或處理多件事情，

且這些功能使用相同的資料(輸入)，但
執行順序沒有相關性。
圖例：

查詢產品規格
查詢庫存數量
產品資料
查詢儲存架位
系統分析與設計 楊子青 D-18

19. (4) 程序內聚力
模組內具有多個功能或處理多件事情，

這些功能必須按照一定的順序來執行，
且不共用相同資料
– 這些功能群集在一個模組內，是為了確保
其執行順序
實例：假設一提款系統之處理如下

讀取提款機 計算客戶
讀取提款
檢查
餘額 存摺餘額
金額
密碼
系統分析與設計 楊子青 D-19

20. (5) 暫時內聚力
模組內具有多個功能或處理多件事情，但是

這些功能僅僅在時序上有所關聯，也就是需
在同一時間內完成，但執行上無先後順序
實例：系統開始時，初始狀態之設定如下

設定日期格式
指定路徑
清除所有變數
設定變數啟始值
系統分析與設計 楊子青 D-20

21. (6) 邏輯內聚力
模組內具有多個邏輯上相關聯的功能。

實例：一系統輸出模組負責輸出錯誤訊息、

使用者的付款日期、報表資料等，至於執行
哪個功能，由上層模組所傳遞之參數決定
錯誤 使用者的 報表 輸出到
訊息 付款日期 資料 印表機上
系統輸出模組
輸出
系統分析與設計 楊子青 D-21

22. (7) 偶發內聚力
一個模組內部要做好幾件工作，且每件工作

都不相干
在設計時，偶發內聚力應盡量避免，例如可

將個別的工作分別獨立出來自成一個模組，
使各模組具有功能內聚力
實例：

列印資產負債表
計算所得稅
查詢庫存量
系統分析與設計 楊子青 D-22

23. 模組內聚力之判定決策樹
是 功能型
否 是
僅 模
順序型
從 組 共用相 資料是否有 是
事 內 同資料 順序性？
溝通型
否
與 各
問 個
程序型
題 活 是
流程 流程是否有
相 動
否 控制 順序性？ 暫時型
否
關 的
的 關
單 係 邏輯型
是
無關 功能邏輯是
一 為
(非以上兩種) 否相關聯？
功 何 偶發型
否
能 ？
系統分析與設計 楊子青 D-23

24. 內聚力之評比因素與比較
依序為：功能、順序、溝通、程序、暫時、

邏輯、偶發
可以接受的內聚力：功能、順序、溝通內聚力

良好的設計希望模組內達到功能內聚力，亦即

一個模組僅處理單一功能
系統分析與設計 楊子青 D-24

25. 2.3.2.2 耦合力
一種衡量模組間相互關聯強度的方法

– 解決了一模組內的錯誤狀況，但在其他的模
組內引起新的錯誤，這種現象稱為連鎖反應
(Ripple Effect)。
– 解決連鎖反應之可行方法是儘量使一個模組
不與其它模組糾結在一起，即讓每個模組儘
可能的獨立，亦即降低模組間的耦合力。
系統分析與設計 楊子青 D-25

26. 五類耦合力
資料耦合力(Data Coupling)

資料結構耦合力(Stamp Coupling)

控制耦合力(Control Coupling)

共同耦合力(Common Coupling)

內容耦合力(Content Coupling)

系統分析與設計 楊子青 D-26

27. (1) 資料耦合力
模組間使用一些簡單型別資料作為兩模

組間傳遞的參數
– 簡單型別資料如整數、浮點、位元等
實例：

計算客戶帳單
貸款總額
償還率
利率
計算房屋
貸款償還
系統分析與設計 楊子青 D-27

28. (2) 資料結構耦合力
模組間以資料結構(Data Structure)型別來傳遞

參數，但並非每個模組均用到該資料結構之所
有欄位。 產生汽車
租金帳單
實例：

租車 租車
– 有一個資料結構稱為
“租車”，有六個欄位：
牌照號碼 計算基本
• 計算油費
汽車租金
會員編號
•
使用汽油量……………用於計算油費
•
汽車款式
•
已開公里數 ………用於計算基本汽車租金
•
租借天數
•
系統分析與設計 楊子青 D-28

29. 資料結構耦合力之評論
可能產生以下的問題：

– 雖然每一個模組可能只用到局部的欄位，但
只要資料結構內任一個欄位修改過，則所有
的相關模組均會受影響。
– 每一個模組使用了比實際需要更多的記憶體
空間。
解決方法：

– 僅傳遞所要用到的欄位，而不必傳遞整個資
料結構，則資料結構耦合力就可變成資料耦
合力。
系統分析與設計 楊子青 D-29

30. (3) 控制耦合力
一模組傳遞旗標去控制另一個模組內的

作業 (內部邏輯)
– 例如有兩個模組：
報表列印
報表列印選擇與產生 選擇
庫存報表或異動報表
，前一個模組傳送旗 列印報表 庫存報表
選擇旗標
標來控制下一個模組 異動報表
做輸入或輸出之動作
產生庫存報表
，則這兩模組間具有
或異動報表
控制耦合力。
系統分析與設計 楊子青 D-30

31. 控制耦合力之評論
控制耦合力有下列兩項缺點：

– 如果被呼叫的模組將拆成兩個以上的模組時
，會因資料的糾結或是需瞭解呼叫模組等而
不易達到目的。
– 撰寫呼叫模組時，如不了解被呼叫的模組，
便不易著手撰寫程式，同時會增加程式測試
的成本。
系統分析與設計 楊子青 D-31

32. (4) 共同耦合力
兩模組使用相同的資料區，且均能夠讀

、寫資料區內之資料
– 實例：下圖兩模組均可讀寫零件表之資料
更新物料 更新庫存
主檔 主檔
無此 無此
料號 料號
產生錯誤訊息旗標表
系統分析與設計 楊子青 D-32

33. 共同耦合力之評論
共同耦合力應儘量少用，主要原因為：

– 如果共用資料產生錯誤，則所有涉及之模組
均會受影響。
– 使用共同資料區的模組名稱均模擬兩可，
不易定義，經常會造成困擾。
– 模組變動時，不知那些資料會被牽動。
系統分析與設計 楊子青 D-33

34. (5) 內容耦合力
一個模組使用另一個模組內之部份程式碼，或

改變其他模組內的局部變數。具有下列特徵：
– 模組以多個進入點(Multi-entry)的方式進入另一模組
– 模組參考或改變其他模組的內部資料。
– 模組改變其他模組內部的執行過程。
此種做法在結構化設計的觀念上是被禁止的

模組 Ｈ： 模組 G：
GO TO G1
GO TO G1 G1:
系統分析與設計 楊子青 D-34

35. 耦合力之評比因素與比較
系統分析與設計 楊子青 D-35

36. 耦合力總結
耦合力愈弱愈好，可以接受的耦合力是

資料耦合力與資料結構耦合力
– 良好的設計希望達到模組間的耦合力為資料
耦合力，即模組間的溝通只使用簡單型別之
參數來溝通。
模組間的耦合力有時可能不只是單純的

一種情形，可能存在兩種以上的耦合力
– 兩模組間的關係以較強的耦合力為準
• 例如兩個模組具有資料結構耦合力和共同耦合力
的關係，則我們應以共同耦合力為準。
系統分析與設計 楊子青 D-36

37. 2.3.2.3 其他考量因素
一個良好的設計除了內聚力與耦合力的

分析外，尚包括：
– 模組功能的分割：當模組太大、為了減少功
能重複的模組、為了管理的需求、為了發展
可重複使用的模組或發展易撰寫的模組等情
況時，都是模組功能分割的適當時機。
– 模組除了原處理外，亦需考量錯誤、輔助訊
息及例外狀況之處理。
系統分析與設計 楊子青 D-37

38. 2.3.3 結構化設計之文件工具
結構圖(Structure Chart)

HIPO圖 (Hierarchical Input Process Output)

模組規格描述

系統模組
{*** 計算送貨明細加總金額 ***}
Begin
移動送貨單的送貨明細資料到第一筆記錄
將送貨單的送貨明細加總金額初值設為0
C
C
VB 當送貨單的送貨明細資料還沒超過最後一筆時，
VA VA
重複以下動作
VB
取有效A 取有效B 產生C資料 列印C資料 Begin
送貨單的送貨明細加總金額＝送貨明細(數量*
售價)＋原送貨單的送貨明細加總金額
移動送貨單的送貨明細資料到下一筆記錄
A B
A VA VB B End;
End;
讀取
讀取
驗證資料
A資料 B資料
註: VA表示validate A
系統分析與設計 楊子青 D-38

39. 2.4 結構化設計
彌補結構化設計之不足

– 結構化設計最終需產出模組化與結構化之程
式和符合正規化之資料庫
• 結構化設計並未具體解決上述問題，因此結構化
分析乃應運而生
– 起源於1970年代中期
– 利用圖形化文件工具(graphic documentation
tools)進行企業流程及企業資料格式塑模
系統分析與設計 楊子青 D-39

40. 結構化分析之圖形化文件工具
事件(Event)及事件列(Event List)

資料流程圖(Data Flow Diagram, DFD)

– 環境圖(Context Diagram)
資料字典 (Data Dictionary, DD)

處理規格描述 (Process Specification, PS)

實體關係圖(Entity Relationship Diagram,

ERD)
系統分析與設計 楊子青 D-40

41. 3. 結構化分析與設計做法
流程塑模 (chap 5)

– 將需求分析階段完成的流程圖、處理描述等，以資
料流程圖進行流程塑模，接著轉成結構圖，再進一
步進行模組設計。
資料塑模 (chap 6)

– 針對藍圖與資料詞彙，以實體關係圖進行資料塑模
，轉成關聯表後，再進行正規化。
使用者介面塑模 (chap 15)

– 利用介面結構圖、介面藍圖與介面元件規格、介面
狀態圖與轉換表等進行介面展示與描述，完成後再
進行進階之使用者介面設計。
系統分析與設計 楊子青 D-41

42. 結構化分析與設計及塑模工具
需求塑模 流程塑模
資料流程圖→結構圖→模組設計
使用者與
企業需求 資料塑模
需求擷取 實體關係圖→關聯表→正規化
需求轉換
使用者介面塑模
流程圖
⊙處理描述 介面結構圖、介面藍圖與元件
⊙藍圖 規格、介面狀態圖與轉換表
⊙資料詞彙
使用者介面設計 程式設計 資料庫設計
系統分析與設計 楊子青 D-42

43. 結構化分析與設計 總結
主要是應用DFD及ERD等圖形化工具，

將企業流程分解成具層級結構之小模組
，並將企業資料格式分解成滿足正規化
之資料庫。
– 有意義之文件模式。
– 使分析與設計過程更視覺化與標準化。
– 有較客觀的準則以供衡量 「好」的系統分析
與設計及程式設計。
– 提升程式的一致性、再用性與可維護性。
系統分析與設計 楊子青 D-43

44. 參考資料
吳仁和、林信惠， 「系統分析與設計：

理論與實務應用」三版，智勝文化事業
有限公司，台北市，2004年1月。
– 第四章：結構化技術
– 第五章：結構化分析與設計「 流程塑模」
系統分析與設計 楊子青 D-44