結構化分析與設計方法是一種面向數據流的需求分析和設計方法，它適用於分析和設計大型數據處理系統，是一種簡單 、 實用的方法，曾獲得廣泛的應用。
1 結構化分析
結構化分析方法的基本思想是自頂向下逐層分解。分解和抽象是人們控制問題複雜性的兩種基本手段。對於一個複雜的問題，人們很難一下子考慮問題的所有方面和全部細節，通常可以把一個大問題分解成若干個小問題，每個小問題再分解成若干個更小的問題，經過多次逐層分解，每個最底層的問題都是足夠簡單 、 容易解決的，於是複雜的問題也就迎刃而解了。這個過程就是分解過程。
結構化分析與面向對象分析方法之間的最大差別是：結構化分析方法把系統看作一個過程的集合體，包括人完成的和電腦完成的；而面向對象方法則把系統看成一個相互影響的對象集。
結構化分析方法的特點是利用數據流圖來幫助人們理解問題，對問題進行分析。結構化分析一般包括以下工具：數據流圖（ Data Flow Diagram ， DFD ） 、 數據字典（ Data Dictionary ， DD ） 、 結構化語言 、 判定表 、 判定樹。
在接下來的部分將對它們一一做簡單介紹。結構化系統分析方法從總體上來看是一種強烈依賴數據流圖的自頂向下的建模方法。它不僅是需求分析技術，也是完成需求規格化的有效技術手段。
1.1 結構化分析的工作步驟
在介紹具體的結構化分析方法之前，先對如何進行結構化分析做一個總結性描述，以幫助大家更好地應用該方法。
（1）研究“物質環境”
首先，應畫出當前系統（可能是非計算機系統，或是半計算機系統）的數據流圖，說明系統的輸入 、 輸出數據流，說明系統的數據流情況，以及經歷了哪些處理過程。在這個數據流圖中，可以包括一些非計算機系統中數據流及處理的命名，例如部門名 、 崗位名 、 報表名等。這個過程可以幫助分析員有效地理解業務環境，在與用戶的充分溝通與交流中完成。
（2）建立系統邏輯模型
當物理模型建立完成之後，接下來的工作就是畫出相對於真實系統的等價邏輯數據流圖。在前一步驟建立的數據流圖的基礎上，將所有自然數據流都轉成等價的邏輯流，例如，將現實世界的報表存儲在計算機系統中的文件裏；又如將現實世界中 “ 送往總經理辦公室 ” 改爲 “ 報送報表 ” 。
（3）劃清人機界限
最後，確定在系統邏輯模型中，哪些將採用自動化完成，哪些仍然保留手工操作。這樣，就可以清晰地劃清系統的範圍。
1.2 數據流圖
DFD 是一種圖形化的系統模型，它在一張圖中展示信息系統的主要需求，即輸入 、 輸出 、 處理（過程） 、 數據存儲。由於從 DFD 中可以很容易地看出系統緊密結合的各個部分，而且整個圖形模式只有5個符號需要記憶，所以深受分析人員的喜愛，因而廣爲流行。如圖 1 所示， DFD 中包括以下幾個基本元素。
（1）數據流圖的層次
正如前面提到的，結構化分析的思路是依賴於數據流圖進行自頂而下的分析。這也是因爲系統通常比較複雜，很難在一張圖上將所有的數據流和加工描述清楚。因此，數據流圖提供一種表現系統高層和低層概念的機制。也就是先繪製一張較高層次的數據流圖，然後在此基礎上，對其中的過程（處理）進行分解，分解成爲若干獨立的 、 低層次的 、 詳細的數據流圖，而且可以這樣逐一地分解下去，直至系統被清晰地描述出來。數據流圖的層次如圖 2 所示。
（2）Context 圖
Context 圖，也就是系統上下文範圍關係圖。這是描述系統最高層結構的 DFD 圖。它的特點是，將整個待開發的系統表示爲一個過程，將所有的外部實體和進出系統的數據流都畫在一張圖中。圖 2 就是一個 Context 圖的例子。
Context 圖用來描述系統有什麼輸入 、 輸出數據流，與哪些外部實體直接相關，可以把整個系統的範圍勾畫出來。
（3）逐級分解
當完成了 Context 圖的建模之後，就可以在此基礎上進行進一步的分解。以圖 3 爲例，進行再分解，在對原有流程瞭解的基礎上，可以得到如圖 4 所示的結果。
圖 4 是在 Context 圖的基礎上做的第一次分解，而在 Context 圖中只有一個過程，那就是系統，將其編號爲 0 。 而接下來對 Context 圖進行的分解，其實就是對這個編號爲 0 的過程進行更細化的描述，在這裏引入了新的過程 、 數據存儲，爲了能夠區分其位置的級別，在這層次上的過程將以1 、 2 、 3爲序列進行編號。由於這是對過程 0 的分解，因此也稱之爲DFD 0 層圖。而可以根據需要對DFD 0 層圖上的過程（編號爲1 、 2 、 3）進行類似的分解，那麼就稱之爲 DFD1 層圖，在 DFD1 層圖中引入的新過程，其編號規則就是 1.1 ， 1.2… ，以及 2.1 ， 2.2… ，以此類推，直到完成分析工作。
另外，這裏存在一個很關鍵的要點，那就是 DFD0 層圖是 Context 圖的細化，因此所有的輸入和輸出應該與 Context 圖完全一致，否則就說明存在錯誤。
（4）如何畫 DFD
DFD 的繪製是一個自頂向下 、 由外到裏的過程，通常按照以下幾個步驟進行。
- 畫系統的輸入和輸出：就是在圖的邊緣標出系統的輸入、輸出數據流。這一步其實是決定研究的內容和系統的範圍。在畫的時候，可以先將盡可能多的輸入、輸出畫出來，然後再刪除多餘的，增加遺漏的。
- 畫數據流圖的內部：將系統的輸入、輸出用一系列的處理連接起來，可以從輸入數據流畫向輸出數據流，也可以從中間畫出去。
- 爲每一個數據流命名：命名的好壞與數據流圖的可理解性密切相關，應避免使用空洞的名字。
- 爲加工命名：注意應該使用動賓短語。
- 不考慮初始化和終點，暫不考慮出錯路徑等細節，不畫控制流和控制信息。
1.3 細化記錄 DFD 部件
爲了更好地描述 DFD 的部件，結構化分析方法還引入了數據字典 、 結構化語言及決策樹 、 決策表等方法。通過使用這些工具，能對數據流圖中描述不夠清晰的地方進行有效的補充。
其中數據字典應用最爲廣泛，下面將詳細說明數據字典的相關使用方法。數據字典技術是一種很實用 、 有效的表達數據格式的手段。它是對所有與系統相關的數據元素的一個有組織的列表和精確嚴格的定義，使得用戶和系統分析員對於輸入 、 輸出 、 存儲成分和中間計算機有共同的理解。
通常數據字典的每一個條目中包括以下信息。
① 名稱：數據或控制項、數據存儲或外部實體的主要名稱，如果有別名的還應該將別名列出來。
② 何處使用/如何使用：使用數據或控制項的加工列表，以及如何使用。
③ 內容描述：說明該條目的內容組成，通常採用以下符號進行說明。
| 符號 | 說明 |
|---|---|
| = | 由…構成。 |
| + | 和，代表順序連接的關係。 |
| [ | ] | 或，代表從中選擇一個。 |
| {}* | n 次重複。 |
| （） | 代表可選的數據項。 |
| *…* | 表示特定限制的註釋。 |
④ 補充信息：關於數據類型、默認值、限制等信息。
下面就是一個數據字典的實例：
客戶基本信息=客戶編號+客戶名稱+身份證號碼+手機+家庭電話
客戶編號 = {0…9}8
客戶名稱 = {字}4
身份證號碼 = [{0…9}15|{0…9}18]
手機 = [{0…9}11|{0…9}12]
家庭電話 =（區號） +本地號區號 = {0…9}4
本地號 = [{0…9}7|{0…9}8]
2 結構化設計
結構化設計包括架構設計 、 接口設計 、 數據設計和過程設計等任務。它是一種面向數據流的設計方法，是以結構化分析階段所產生的成果爲基礎，進一步自頂而下 、 逐步求精和模塊化的過程。
2.1 概要設計與詳細設計的主要任務
概要設計階段的主要任務是設計軟件的結構 、 確定系統是由哪些模塊組成，以及每個模塊之間的關係。它採用結構圖（包括模塊 、 調用 、 數據）來描述程序的結構，此外還可以使用層次圖和 HIPO （層次圖加輸入 / 處理 / 輸出圖）。
整個過程主要包括：複查基本系統模型 、 複查並精化數據流圖 、 確定數據流圖的信息流類型（包括交換流和事務流） 、 根據流類型分別實施變換分析或事務分析 、 根據軟件設計原則對得到的軟件結構圖進一步優化。
而詳細設計階段的主要任務則是確定應該如何具體地實現所要求的系統，得出對目標系統的精確描述。它採用自頂向下 、 逐步求精的設計方式和單入口單出口的控制結構。常使用的工具包括程序流程圖 、 盒圖 、 PAD（ Problem Analysis Diagram ，問題分析圖） 、 PDL（ Program Design Language ，程序設計語言）。
2.2 結構圖
結構圖的基本成分包括模塊 、 調用（模塊之間的調用關係）和數據（模塊間傳遞及處理數據信息）。
結構圖是在需求分析階段產生的數據流圖的基礎上進行進一步的設計。它將 DFD 圖中的信息流分爲兩種類型。
- 變換流：信息首先沿着輸入通路進入系統，並將其轉換爲內部表示，然後通過變換中心（加工）的處理，再沿着輸出轉換爲外部形式離開系統。具有這種特性的加工流就是變換流。
- 事務流：信息首先沿着輸入通路進入系統，事務中心根據輸入信息的類型在若干個動作序列（活動流）中選擇一個執行，這種信息流稱爲事務流。
2.3 程序流程圖和盒圖
程序流程圖和盒圖都是用來描述程序的細節邏輯的，程序流程圖的符號如圖 5 所示。
程序流程圖的特點是簡單 、 直觀 、 易學，但它的缺點也正是由於其隨意性而使得畫出來的流程圖容易成爲非結構化的流程圖。而盒圖正是爲了解決這一問題設計的，它是一種符合結構化程序設計原則的圖形描述工具。盒圖的主要特點是功能域明確 、 無法任意轉移控制 、 容易確定全局數據和局部數據的作用域 、 容易表示嵌套關係 、 可以表示模塊的層次結構。但它也帶來了一個副作用，那就是修改相對比較困難。
2.4 PAD 和 PDL
PAD （Problem Analysis Diagram）是問題分析圖的縮寫，它符合自頂向下 、 逐步求精的原則，也符合結構化程序設計的思想，它最大的特點在於能夠很方便地轉換爲程序語言的源程序代碼 。
PDL （Process Design Language）則是過程設計語言的縮寫，它和高級程序語言很相似，也包括數據說明部分和過程部分，還可以帶註解等成分，但它是不可執行的 。PDL 是一種形式化語言，其控制結構的描述是確定的，但內部的描述語法是不確定的 。PDL 通常也被稱爲僞碼。
3 模塊設計
在結構化方法中，模塊化是一個很重要的概念，它是將一個待開發的軟件分解成爲若干個小的簡單部分 —— 模塊，每個模塊可以獨立地開發 、 測試。這是一種複雜問題的 “ 分而治之 ” 原則，其目的是使程序的結構清晰 、 易於測試與修改。
具體來說，模塊是指執行某一特定任務的數據結構和程序代碼。通常將模塊的接口和功能定義爲其外部特性，將模塊的局部數據和實現該模塊的程序代碼稱爲內部特性。而在模塊設計時，最重要的原則就是實現信息隱蔽和模塊獨立。
模塊經常具有連續性，也就意味着作用於系統的小變動將導致行爲上的小變化，同時規模說明的小變動也將影響到一小部分模塊。
3.1 信息隱蔽原則
信息隱蔽是開發整體程序結構時使用的法則，即將每個程序的成分隱蔽或封裝在一個單一的設計模塊中，並且儘可能少地暴露其內部的處理。通常將難的決策 、 可能修改的決策 、 數據結構的內部連接以及對它所做的操作細節 、 內部特徵碼 、 與計算機硬件有關的細節等隱蔽起來。通過信息隱蔽可以提高軟件的可修改性 、 可測試性和可移植性，它也是現代軟件設計的一個關鍵性原則。
3.2 模塊獨立性原則
模塊獨立是指每個模塊完成一個相對獨立的特定子功能，並且與其他模塊之間的聯繫最簡單。保持模塊的高度獨立性，也是設計過程中的一個很重要的原則。通常用耦合（模塊之間聯繫的緊密程度）和內聚（模塊內部各元素之間聯繫的緊密程度）兩個標準來衡量，設計的目標是高內聚 、 低耦合。模
塊的內聚類型通常可以分爲7種，根據內聚度從高到低排序，如下表所示。
| 內聚類型 | 描述 |
|---|---|
| 偶然內聚或巧合內聚 | 指一個模塊內的各處理元素之間沒有任何聯繫。 |
| 邏輯內聚 | 指模塊內執行若干個邏輯上相似的功能，通過參數確定該模塊完成哪一個功能。 |
| 時間內聚 | 把需要同時執行的動作組合在一起形成的模塊。 |
| 過程內聚 | 指一個模塊完成多個任務，這些任務必須按指定的過程執行。 |
| 通信內聚 | 指模塊內的所有處理元素都在同一數據結構上操作，或者各處理使用相同的輸入數據或產生相同的輸出數據。 |
| 順序內聚 | 指一個模塊中的各個處理元素都密切相關，且各功能且必須順序執行，前一個功能元素的輸出就是下一個功能的輸入。 |
| 功能內聚 | 指模塊內的所有元素共同作用完成一個功能，缺一不可。 |
與此相對應的，模塊的耦合性類型通常也分爲7種，根據耦合度從低到高排序，如下表所示。
| 耦合類型 | 說明 |
|---|---|
| 無直接耦合 | 無直接聯繫，互不依賴。 |
| 數據耦合 | 藉助參數表傳遞簡單數據。 |
| 標記耦合 | 一個數據結構的一部分藉助於模塊接口傳遞。 |
| 控制耦合 | 傳遞的是控制變量，例如開關、標誌等。 |
| 外部耦合 | 與軟件之外的環境有關，比如I/O環境。 |
| 公共耦合 | 多個模塊引用的是同一個全局數據區，比如公共數據環境中的數據。 |
| 內容耦合 | 一個模塊訪問另一個模塊的內部數據；一個模塊通過特殊入口進入另一個模塊內部；兩個模塊有一部分程序代碼重疊；一個模塊有多個入口。 |
除了滿足以上兩大基本原則之外，通常在模塊分解時還需要注意：
- 保持模塊的大小適中，儘可能減少調用的深度，直接調用該模塊的個數應該儘量大，但調用其他模塊的個數則不宜過大；
- 保證模塊是單入口、單出口的；
- 模塊的作用域應該在控制域之內；
- 功能應該是可預測的。