作者：薛勤

主頁：https://github.com/yueshutong

本文使用 BlogHelper 一鍵釋出本地文章帶本地圖片到部落格平臺。

一、前言

軟體工程中規定，軟體生命週期由軟體定義、軟體開發和執行維護（也稱為軟體維護）3個時期組成，每一個時期又進一步劃分為若干個階段。

• 軟體定義時期包括問題定義、可行性研究、需求分析三個階段。

• 軟體開發時期包括總體設計、詳細設計、編碼和單元測試、綜合測試四個階段。

• 軟體維護時期只包括軟體維護這一個階段。

本文旨在說明在軟體生命週期不同階段的各種圖的含義與使用。

二、可行性研究

2.1 系統流程圖

系統流程圖是概括地描繪物理系統的傳統工具。它的基本思想是用圖形符號以黑盒子形式描繪組成系統的每個部件（程式、文件、資料庫、人工過程等）。系統流程圖表達的資料在系統各部件之間流動的情況，而不是對資料進行加工處理的控制過程，因此儘管系統流程圖的某些符號和程式流程圖的符號形式相同，但是它卻是物理資料流圖而不是程式流程圖。

符號

當以概括的方式抽象的描繪一個實際系統時，僅僅使用圖2.1中列出的基本符號就足夠了。當需要更具體地描繪一個物理系統時還需要使用圖2.2中列出的系統符號，利用這些符號可以把一個廣義的輸入輸出操作具體化為讀寫儲存在特殊裝置上的檔案（或資料庫），把抽象處理具體化為特定的程式或手工操作等。

用法

例子

分層

面對複雜的系統時，一個比較好的方法是分層次地描繪這個系統。首先用一張高層次的系統流程圖描繪系統總體概貌，表明系統的關鍵功能。然後分別把每個關鍵功能擴充套件到適當的詳細程度，畫在單獨的一頁紙上。這種分層次的描繪方法便於閱讀者按從抽象到具體的過程逐步深入地瞭解一個複雜的系統。

2.2 資料流圖

資料流圖（DFD）是一種圖形化技術，它描繪資訊流和資料從輸入移動到輸出的過程中所經受的變換。在資料流圖中沒有任何具體的物理部件，它只是描繪資料在軟體中流動和被處理的邏輯過程。資料流圖是系統邏輯功能的圖形表示，即使不是專業的計算機技術人員也容易理解它，因此是分析員與使用者之間極好的通訊工具。此外，設計資料流圖時只需要考慮系統必須完成的基本邏輯功能，完全不需要考慮樣具體的實現這些功能，所以它也是今後進行軟體設計的很好的出發點。

符號

例子

三、需求分析

3.1 實體-聯絡圖

為了把使用者的資料要求清楚、準確地描述出來，系統分析員通常建立一個概念性的資料模型（也稱為資訊模型）。概念性資料模型是一種面向問題的資料模型，是按照使用者的觀點對資料建立的模型。它描述了從使用者角度看到的資料，它反映了使用者的現實環境，而且與在軟體系統中的實現方法無關。資料模型中包含 3 種相互關聯的資訊：資料物件、資料物件的屬性及資料物件彼此間相互連線的關係。

通常，使用實體-聯絡圖（entity-relationship diagram）來建立資料模型。可以把實體-聯絡圖簡稱為 ER 圖，相應地可把用 ER 圖描繪的資料模型稱為 ER 模型。

符號

ER 圖中包含了實體、關係和屬性 3 種基本成分，通常用矩形框代表實體，用連線相關實體的菱形框表示關係，用橢圓形或圓角矩形表示實體（或關係）的屬性，並用直線把實體（或關係）與其屬性連線起來。

例子

3.2 狀態轉換圖

在需求分析過程中應該建立起軟體系統的行為模型。狀態轉換圖（簡稱為狀態圖）通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。此外，狀態圖還指明瞭作為特定事件的結果系統將做哪些動作（例如，處理資料）。

狀態

狀態是任何可以被觀察到的系統行為模式，一個狀態代表系統的一種行為模式。狀態規定了系統對事件的響應方式。系統對事件的響應，既可以是做一個(或一系列)動作，也可以是僅僅改變系統本身的狀態，還可以是既改變狀態又做動作。

在狀態圖中定義的狀態主要有：初態（即初始狀態）、終態（即最終狀態）和中間狀態。在一張狀態圖中只能有一個初態，而終態則可以有 0 至多個。

狀態圖既可以表示系統迴圈執行過程，也可以表示系統單程生命期。當描繪迴圈執行過程時，通常並不關心迴圈是怎樣啟動的。當描繪單程生命期時，需要標明初始狀態（系統啟動時進入初始狀態）和最終狀態（系統執行結束時到達最終狀態）。

事件

事件是在某個特定時刻發生的事情，它是對引起系統做動作或（和）從一個狀態轉換到另一個狀態的外界事件的抽象。例如，內部時鐘表明某個規定的時間段已經過去，使用者移動或單擊滑鼠等都是事件。簡而言之，事件就是引起系統做動作或（和）轉換狀態的控制資訊。

符號

在狀態圖中，初態用實心圓表示，終態用一對同心圓（內圓為實心圓）表示。
中間狀態用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下 3 個部分。上面部分為狀態的名稱，這部分是必須有的；中間部分為狀態變數的名字和值，這部分是可選的；下面部分是活動表，這部分也是可選的。

活動表的語法格式如下：

事件名（引數表）/ 動作表示式

其中，“事件名”可以是任何事件的名稱。在活動表中經常使用下述 3 種標準事件：entry，exit 和 do。 entry 事件指定進入該狀態的動作，exit 事件指定退出該狀態的動作，而 do 事件則指定在該狀態下的動作。需要時可以為事件指定引數表。活動表中的動作表示式描述應做的具體動作。

狀態圖中兩個狀態之間帶箭頭的連線稱為狀態轉換，箭頭指明瞭轉換方向。狀態變遷通常是由事件觸發的，在這種情況下應在表示狀態轉換的箭頭線上標出觸發轉換的事件表示式；如果在箭頭線上未標明事件，則表示在源狀態的內部活動執行完之後自動觸發轉換。

事件表示式的語法如下：

事件說明[守衛條件] / 動作表示式

其中，事件說明的語法為：事件名（引數表）。

守衛條件是一個布林表示式。如果同時使用事件說明和守衛條件，則當且僅當事件發生且布林表示式為真時，狀態轉換才發生。如果只有守衛條件沒有事件說明，則只要守衛條件為真，狀態轉換就發生。

動作表示式是一個過程表示式，當狀態轉換開始時執行該表示式。

圖 3.3 給出了狀態圖中使用的主要符號。

例子

3.3 層次方框圖

層次方框圖用樹形結構的一系列多層次的矩形框描繪資料的層次結構。樹形結構的頂層是一個單獨的矩形框，它代表完整的資料結構，下面的各層矩形框代表這個資料的子集，最底層的各個框代表組成這個資料的實際資料元素（不能再分割的元素）。

例子

3.4 Warnier圖

法國電腦科學家 Warnier 提出了表示資訊層次結構的另外一種圖形工具— Warnier 圖。和層次方框圖類似，Warnier 圖也用樹形結構描繪資訊，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。

用 Warnier 圖可以表明資訊的邏輯組織，也就是說，它可以指出一類資訊或一個資訊元素是重複出現的，也可以表示特定資訊在某一類資訊中是有條件地出現的。因為重複和條件約束是說明軟體處理過程的基礎，所以很容易把 Warnier 圖轉變成軟體設計的工具。

例子

圖中花括號用來區分資料結構的層次，在一個花括號內的所有名字都屬於同一類資訊；異
或符號（⊕）表明一類資訊或一個數據元素在一定條件下才出現，而且在這個符號上、下方
的兩個名字所代表的資料只能出現一個；在一個名字下面（或右邊）的圓括號中的數字指明瞭這個名字代表的資訊類（或元素）在這個資料結構中重複出現的次數。（例如 P1 種、 P2 種）

3.5 IPO圖

IPO 圖是輸入、處理、輸出圖的簡稱，它是由美國 IBM 公司發展完善起來的一種圖形工具，能夠方便地描繪輸入資料、對資料的處理和輸出資料之間的關係。

IPO 圖使用的基本符號既少又簡單，因此很容易學會使用這種圖形工具。它的基本形式是在左邊的框中列出有關的輸入資料，在中間的框內列出主要的處理，在右邊的框內列出產生的輸出資料。處理框中列出處理的次序暗示了執行的順序，但是用這些基本符號還不足以精確描述執行處理的詳細情況。在IPO圖中還用類似向量符號的粗大箭頭清楚地指出資料通訊的情況。

例子

四、總體設計

4.1 層次圖

層次圖用來描繪軟體的層次結構。層次圖中的一個矩形框代表一個模組，方框間的連線表示呼叫關係而不像層次方框圖那樣表示組成關係。

例子

4.2 HIPO圖

HIPO 圖是美國 IBM 公司發明的“層次圖加輸入/處理/輸出圖”的英文縮寫。為了能使 HIPO 圖具有可追蹤性，在 H 圖（層次圖）裡除了最頂層的方框之外，每個方框都加了編號。

例子

4.3 結構圖

Yourdon 提出的結構圖是進行軟體結構設計的另一個有力工具。結構圖和層次圖類似，也是描繪軟體結構的圖形工具，圖中一個方框代表一個模組，框內註明模組的名字或主要功能；方框之間的箭頭（或直線）表示模組的呼叫關係。

在結構圖中通常還用帶註釋的箭頭表示模組呼叫過程中來回傳遞的資訊。如果希望進一步標明傳遞的資訊是資料還是控制資訊，則可以利用註釋箭頭尾部的形狀來區分：尾部是空心圓表示傳遞的是資料，實心圓表示傳遞的是控制資訊。

例子

五、詳細設計

5.1 程式流程圖

程式流程圖又稱為程式框圖，它是歷史最悠久、使用最廣泛的描述過程設計的方法，然而它也是用得最混亂的一種方法。

從20世紀40年代末到70年代中期，程式流程圖一直是軟體設計的主要工具。它的主要優點是對控制流程的描繪很直觀，便於初學者掌握。由於程式流程圖歷史悠久，為最廣泛的人所熟悉，儘管它有種種缺點，許多人建議停止使用它，但至今仍在廣泛使用著。不過總的趨勢是越來越多的人不再使用程式流程圖了。

程式流程圖的主要缺點如下。

1. 程式流程圖本質上不是逐步求精的好工具，它誘使程式設計師過早地考慮程式的控制流程，而不去考慮程式的全域性結構。
2. 程式流程圖中用箭頭代表控制流，因此程式設計師不受任何約束，可以完全不顧結構程式設計的精神，隨意轉移控制。
3. 程式流程圖不易表示資料結構。

符號

例子

5.2 盒圖

出於要有一種不允許違背結構程式設計精神的圖形工具的考慮，Nassi 和 Shneiderman 提出了盒圖，又稱為 N-S 圖。它有下述特點。

1. 功能域（即，一個特定控制結構的作用域）明確，可以從盒圖上一眼就看出來。
2. 不可能任意轉移控制。
3. 很容易確定區域性和全程資料的作用域。
4. 很容易表現巢狀關係，也可以表示模組的層次結構。

符號

5.3 PAD 圖

PAD 圖是問題分析圖（problem analysis diagram）的英文縮寫，自 1973年由日本日立公司發明以後，已得到一定程度的推廣。它用二維樹形結構的圖來表示程式的控制流，將這種圖翻譯成程式程式碼比較容易。

符號

優點

PAD圖的主要優點如下：

1. 使用表示結構化控制結構的 PAD 符號所設計出來的程式必然是結構化程式。
2. PAD 圖所描繪的程式結構十分清晰。圖中最左面的豎線是程式的主線，即第一層結構。隨著程式層次的增加，PAD 圖逐漸向右延伸，每增加一個層次，圖形向右擴充套件一條豎線。PAD 圖中豎線的總條數就是程式的層次數。
3. 用 PAD 圖表現程式邏輯，易讀、易懂、易記。PAD圖是二維樹形結構的圖形，程式從圖中最左豎線上端的結點開始執行，自上而下，從左向右順序執行，遍歷所有結點。
4. 容易將 PAD 圖轉換成高階語言源程式，這種轉換可用軟體工具自動完成，從而可省去人工編碼的工作，有利於提高軟體可靠性和軟體生產率。
5. 即可用於表示程式邏輯，也可用於描繪資料結構。
6. PAD 圖的符號支援自頂向下、逐步求精方法的使用。開始時設計者可以定義一個抽象的程式，隨著設計工作的深入而使用 def 符號逐步增加細節，直至完成詳細設計。

例子

5.4 判定表

判定表能夠清晰地表示覆雜的條件組合與應做的動作之間的對應關係。

判定表由 4 部分組成，左上部分列出所有條件，左下部是所有可能做的動作，右上部是表示各種條件組合的一個矩陣，右下部是和每種條件組合相對應的動作。判定表右半部的每一列實質上是一條規則，規定了與特定的條件組合相對應的動作。

例子

5.5 判定樹

判定表雖然能清晰地表示覆雜的條件組合與應做的動作之間的對應關係，但其含義卻不是一眼就能看出來的。

判定樹是判定表的變種，它也能清晰地表示覆雜的條件組合與應做的動作之間的對應關係.

例子

六、後記

本文簡要描述了軟體工程中經常用到的一些圖，其實還有很多圖沒有介紹到，比如UML（標準圖、類圖）等，感興趣的小夥伴可以自行學習。

參考資料

《軟體工程導論