第5章總體設計設計過程設計原理啟發規則描繪軟件結構的圖形工具面向數據流的設計方法小結總體設計的任務就是回答“系統應該如何實現?”總體設計又稱為概要設計或初步設計。這個階段的主要工作是劃分出組成系統的物理元素——程序、數據庫和文檔等等。這個階段的另一工作是設計軟件的結構，也就是要確定系統中每個程序是由哪些模塊組成的，以及這些模塊相互間的關系。總體設計過程通常由兩個主要階段組成：系統設計階段，確定系統的具體實現方案；設想供選擇的方案選取合理的方案推薦最佳方案5.1

設計過程(2)結構設計階段，確定軟件結構。功能分解設計軟件結構設計數據庫典型的總體設計過程包括下述9個步驟：設想供選擇的方案在總體設計階段分析員應該考慮各種可能的實現方案。選取合理的方案應該從前一步得到的一系列供選擇的方案中選取若干個合理的方案，對每個合理的方案分析員都應該準備下列4份資料：系統流程圖；組成系統的物理元素清單；成本/效益分析；實現這個系統的進度計劃。3.

推薦最佳方案分析員應該綜合分析對比各種合理方案的利弊，推薦一個最佳的方案，并且為推薦的方案制定詳細的實現計劃。用戶和有關的技術專家應該認真審查分析員所推薦的最佳系統，再提請使用部門負責人進一步審批。在使用部門的負責人也接受了分析員所推薦的方案之后，將進入總體設計過程的下一個重要階段——結構設計。功能分解為了最終實現目標系統，必須設計出組成這個系統的所有程序和文件(或數據庫)。對程序的設計，通常分為兩個階段完成：首先進行結構設計，然后進行過程設計。結構設計確定程序由哪些模塊組成，以及這些模塊之間的關系；過程設計確定每個模塊的處理過程。5.

設計軟件結構把模塊組織成良好的層次系統，頂層模塊調用它的下層模塊以實現程序的完整功能，每個下層模塊再調用更下層的模塊，從而完成程序的一個子功能，最下層的模塊完成最具體的功能。軟件結構可以用層次圖或結構圖來描繪。6.

設計數據庫在數據庫課中詳細講述。5.2

設計原理5.2.1

模塊化模塊是構成程序的基本構件。模塊化就是把程序劃分成獨立命名且可獨立訪問的部分，每個部分完成一個子功能，這樣的部分就是模塊，把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求。設函數C(x)定義問題x的復雜程度，函數E(x)確定解決問題x需要的工作量(時間)。若C(X1)>C(X2),

根據人類解決一般問題的經驗，通常的規律是：E(X1)>E(X2)對于一個問題P，若可分解成P1和P2，即P=P1+P2，根據人類解決一般問題的經驗，同樣也有規律：C(P1+P2)>C(P1)+C(P2)因此就有：E(P1+P2)>E(P1)+E(P2)即：E(P)>E(P1)+E(P2)不等式E(P)>E(P1)+E(P2)把復雜的問題分解成許多容易解決的小問題，原來的問題也就容易解決了。由上面的不等式似乎還能得出下述結論：如果無限地分割軟件，似乎開發軟件而需要的工作量也就小得可以忽略了？但是，隨著模塊數目增加，設計模塊間接口所需要的工作量也將增加。根據這兩個因素，得出了圖中的總成本曲線。每個程序都相應地有一個最適當的模塊數目M，使得系統的開發成本最小。開發具有特定功能而且和其他模塊之間沒有過多的相互作用的模塊，就可以做到模塊獨立。5.2.5

模塊獨立模塊獨立的重要性：比較容易開發,這是由于容易分割且接口可以簡化，當許多人分工合作開發同一個軟件時，這個優點尤其重要。比較容易測試和維護, 這是因為相對說來，修改設計和程序需要的工作量比較小，錯誤傳播范圍小，需要擴充功能時能夠“插入”模塊。模塊的獨立程度的兩個標準:(內聚和耦合)。1.

耦合(衡量不同模塊間互相依賴的程度)耦合是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度。①如果兩個模塊彼此間通過參數交換信息，而且交換的信息僅僅是數據，那么這種耦合稱為數據耦合;②如果傳遞的信息中有控制信息(盡管有時這種控制信息以數據的形式出現)，則這種耦合稱為控制耦合;控制型耦合轉變為數據型耦合一般來說，控制型耦合是不必要的，可以通過分裂模塊等方法把控制型耦合轉變成數據型耦合。A取陰歷取陽歷A取陽歷日期或取陰歷日期日期類型選擇陰歷日期陽歷日期③當兩個或多個模塊通過一個公共數據環境相互作用時，它們之間的耦合稱為公共環境耦合;④若一個模塊訪問另一個模塊的內部數據或一個模塊不通過正常入口而轉到另一個模塊的內部或兩個模塊有一部分程序代碼重疊或一個模塊有多個入口，則這種耦合稱為內容耦合。盡量使用數據耦合，少用控制耦合，限制公共環境耦合，完全不用內容耦合。2.

內聚（標志一個模塊內各個元素彼此結合的緊密程度）內聚有如下7類：如果一個模塊完成一組任務，這些任務彼此間即使有關系，關系也是很松散的，就叫做偶然內聚。若一個模塊可實現多個邏輯上相似的一類功能，則稱該模塊的內聚為邏輯內聚。如果一個模塊包含的任務必須在同一段時間內執行，就叫時間內聚。如果一個模塊內的處理元素是相關的，而且必須以特定次序執行，則稱為過程內聚。如果模塊中所有元素都使用同一個輸入數據和(或)產生同一個輸出數據，則稱為通信內聚。如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執行(通常一個處理元素的輸出數據作為下一個處理元素的輸入數據)，則稱為順序內聚。如果模塊內所有處理元素屬于一個整體，完成一個單一的功能，則稱為功能內聚。功能內聚是最高程度的內聚。偶偶偶偶邏邏偶偶低偶偶時時偶偶過過偶偶通通偶偶中偶偶順順偶偶功功偶偶高偶偶低高內聚性的排列如果給上述七種內聚排列，將得到如下結果：設計時應該力求做到高內聚，通常中等程度的內聚也是可以采用的，而且效果和高內聚相差不多；但是，低內聚很壞，不要使用。內聚和耦合是密切相關的，模塊內的高內聚往往意味著模塊間的松耦合。內聚和耦合都是進行模塊化設計的有力工具，但是實踐表明內聚更重要。人們在開發計算機軟件的長期實踐中積累了豐富的經驗，總結這些經驗得出了一些啟發式規則。下面介紹幾條啟發式規則。5.3

啟發規則1.

改進軟件結構提高模塊獨立性設計出軟件的初步結構以后，應該審查分析這個結構，通過模塊分解或合并，力求降低耦合提高內聚。例如，多個模塊公有的一個子功能可以獨立成一個模塊，由這些模塊調用；有時可以通過分解或合并模塊以減少控制信息的傳遞及對全程數據的引用，并且降低接口的復雜程度。2.

模塊規模應該適中經驗表明，一個模塊的規模不應過大，最好能寫在一頁紙內(通常不超過60行語句)。有人從心理學角度研究得知，當一個模塊包含的語句數超過30以后，模塊的可理解程度迅速下降。3.

深度、寬度、扇出和扇入都應適當深度表示軟件結構中控制的層數，它往往能粗略地標志一個系統的大小和復雜程度。寬度是軟件結構內同一個層次上的模塊總數的最大值。一般說來，寬度越大系統越復雜。對寬度影響最大的因素是模塊的扇出。扇出是一個模塊直接控制(調用)的模塊數目，經驗表明，一個設計得好的典型系統的平均

扇出通常是3或4(扇出的上限通常是5～9)。一個模塊的扇入表明有多少個上級模塊直接調用它。思考題M1M2MnM…(a)(b)M1M2MkM…圖5.5

模塊的扇入和扇出(a)扇入；(b)扇出觀察大量軟件系統后發現，設計得很好的軟件結構通常頂層扇出比較高，中層扇出較少，底層扇入到公共的實用模塊中去(底層模塊有高扇入)。4.

模塊的作用域應該在控制域之內模塊的作用域定義為受該模塊內判定影響的所有模塊的集合。模塊的控制域是這個模塊本身以及所有直接或間接從屬于它的模塊的集合。例如，在圖5.2中模塊A的控制域肯定是A、B、C、D、E和F模塊的集合。但其作用域可能超出A、B、C、D、E、F的范圍。圖5.2

模塊的作用域和控制域作用域題力爭降低模塊接口的復雜程度模塊接口復雜是軟件發生錯誤的一個主要原因。應該仔細設計模塊接口，使得信息傳遞簡單并且和模塊的功能一致。設計單入口單出口的模塊當從頂部進入模塊并且從底部退出來時，軟件是比較容易理解的，因此也是比較容易維護的。7.

模塊功能應該可以預測模塊的功能應該能夠預測，但也要防止模塊功能過分局限。如果一個模塊可以當做一個黑盒子，也就是說，只要輸入的數據相同就產生同樣的輸出，這個模塊的功能就是可以預測的。帶有內部“存儲器”的模塊的功能可能是不可預測的，因為它的輸出可能取決于內部存儲器(例如某個標記)的狀態。改進軟件結構設計的指導原則(軟件結構設計的啟發式規則)(1)模塊功能的完善化

(2)消除重復功能(3)將模塊的影響限制在模塊的控制范圍內

(4)深度、寬度、扇出和扇入適中

(5)模塊大小適中

(6)降低模塊接口的復雜性

(7)模塊功能可預測(1)模塊功能的完善化完整的模塊應包括三部分：

(1)執行規定功能部分

(2)出錯處理部分(3)需返回給調用者數據時，返回是否正確結束標志。(2)消除重復功能Q1CQ2CQ1

Q2CXYQ’YX

XY重復部分改進前

Q1、Q2功能相似改進方法1：將Q1、Q2

合并為Q’不可取改進方法2：將Q1、Q2的公共部分分離出來(3)將模塊的影響限制在模塊的控制范圍內CHDEGXFAILJKB模塊C的控制范圍:C、D、E、F、G、H如果模塊

C作出的決策影響了模塊L，L超出了C的控制范圍(4)減少高扇出爭取高扇入編外人員工資取得工資數據計時制工資額薪金制工資額編外人員稅款編外人員扣款常規扣款稅收扣款計算實發工資避免平鋪結構增加中間層降低扇出取得工資數據計時制工資額薪金制工資額編外編外編外人員人員人員工資稅款扣款常規扣款稅收扣款計算實發工資計時工人實發工資計薪工人實發工資編外人員實發工資(5)模塊大小適中模塊過大：可理解程度下降模塊過小：開銷大于有效操作系統接口復雜(6)降低模塊接口的復雜性接口傳遞信息應簡單且和模塊功能一致。(7)模塊功能可預測模塊看成黑盒子，相同輸入產生相同輸出，其功能為可預測的。模塊帶有內部狀態其功能可能是不可預測的。難理解、難測試、難維護。面向數據流的設計方法可以把數據流圖變換成軟件結構。因為任何軟件系統都可以用數據流圖表示，所以面向數據流的設計方法理論上可以設計任何軟件的結構。通常所說的結構化設計方法(簡稱SD方法)，也就是基于數據流的設計方法。5.5

面向數據流的設計方法面向數據流的設計方法把信息流映射成軟件結構，信息流的類型決定了映射的方法。信息流有下述兩種類型。1.

變換流參看圖5.8，信息沿輸入通路進入系統，同時由外部形式變換成內部形式，進入系統的信息通過變換中心，經加工處理以后再沿輸出通路變換成外部形式離開軟件系統。5.5.1

概念圖5.8變換流2.

事務流當數據沿輸入通路到達一個處理，這個處理根據輸入數據的類型在若干個動作序列中選出一個來執行。這類數據流稱為事務流。相應的處理稱為事務中心，它完成下述任務：接收輸入數據(輸入數據又稱為事務)；分析每個事務以確定它的類型；根據事務類型選取一條活動通路。圖5.9事務流變換分析是