細數軟件工程各階段必不可少的那些圖

2020 年 1 月 31 日
筆記

作者：薛勤主頁：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年代中期，程序流程圖一直是軟件設計的主要工具。它的主要優點是對控制流程的描繪很直觀，便於初學者掌握。由於程序流程圖歷史悠久，為最廣泛的人所熟悉，儘管它有種種缺點，許多人建議停止使用它，但至今仍在廣泛使用着。不過總的趨勢是越來越多的人不再使用程序流程圖了。

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

程序流程圖本質上不是逐步求精的好工具，它誘使程序員過早地考慮程序的控制流程，而不去考慮程序的全局結構。
程序流程圖中用箭頭代表控制流，因此程序員不受任何約束，可以完全不顧結構程序設計的精神，隨意轉移控制。
程序流程圖不易表示數據結構。

符號

例子

5.2 盒圖

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

功能域（即，一個特定控制結構的作用域）明確，可以從盒圖上一眼就看出來。
不可能任意轉移控制。
很容易確定局部和全程數據的作用域。
很容易表現嵌套關係，也可以表示模塊的層次結構。

符號

5.3 PAD 圖

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

符號

優點

PAD圖的主要優點如下：

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

例子

5.4 判定表

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

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

例子

5.5 判定樹

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

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

例子

六、後記

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

參考資料

《軟件工程導論》