《軟件工程》課件-第4章 總體設計

第4章

總體設計XX大學XX系XXX軟件工程教程電子科技大學出版社學習目標l

了解總體設計的目標、任務和設計過程；l

理解總體設計的原理和結構設計準則；l

掌握面向數(shù)據流的軟件結構設計方法和描繪軟件結構的圖形工具；l

能夠運用相關方法和工具進行簡單的軟件結構設計。目錄010203總體設計的目標和任務總體設計的過程總體設計的原理04050607軟件結構設計準則描繪軟件結構的圖形工具面向數(shù)據流的軟件結構設計方法本章小結總體設計的目標和任務01總體設計的目標和任務按照軟件生存周期模型的結構，總體設計（也稱概要設計）是在需求分析取得正式結果的基礎上開展的軟件開發(fā)工作，是軟件開發(fā)時期的第一階段工作，對開發(fā)時期的其他后續(xù)工作具有統(tǒng)籌的作用?？傮w設計的目標和任務總體設計的基本目的是回答“概括地說，系統(tǒng)應該如何實現(xiàn)”這個問題，目標是得到良好的軟件總體結構，即獨立性良好、規(guī)模適中的一組模塊以及深度、寬度、扇入、扇出合適的系統(tǒng)結構。良好的總體結構將給后續(xù)階段的工作帶來諸多便利，也是保障軟件質量、降低開發(fā)成本、提高軟件可維護性的先決條件。什么是良好的軟件結構？如何設計良好的軟件結構？可以使用哪些工具？將是本章主要介紹的內容。總體設計的目標和任務從工程管理的角度，軟件設計可以劃分為兩個階段：總體設計階段和詳細設計階段。總體設計的目標是把需求分析得到的結構化分析模型映射成結構化設計模型。前者反映的是問題域的既定事實，后者反映的是帶有設計者意圖的或意志的預期事實。結構化分析與結構化設計的關系如圖4.1所示?？傮w設計的圖4.1分析模型到設計模型的映射總體設計的目標和任務需要明白的是，分析模型不是設計的結果，分析模型要如實反映問題域的真實情況；設計模型要以分析模型為基礎，用計算機所理解的虛擬世界的方式對問題域中待解決的問題進行重新的結構構建，并反映設計這的意志，設計模型絕不能違反分析模型中的事實和現(xiàn)實世界的常識，否則，就不可能得到符合預期的產品?？傮w設計的目標和任務總體設計的主要任務是把分析階段得到的數(shù)據模型映射成數(shù)據庫設計，把數(shù)據流圖映射成軟件功能結構，行為模型可以用于詳細設計階段的流程、算法設計。軟件功能結構反映了軟件的功能組成，以及各功能模塊間的邏輯關系（含接口關系）?？傮w設計的過程02總體設計的過程總體設計過程通常由兩個主要階段組成：系統(tǒng)設計階段，確定系統(tǒng)的的具體實現(xiàn)方案；”結構設計階段，確定軟件的結構。典型的總體設計過程包括以下九個步驟?？傮w設計的過程（1）設想供選擇的方案在總體設計階段，系統(tǒng)分析員首先應該考慮各種可能的實現(xiàn)方案，并力求選出最佳方案。設”想方案的出發(fā)點是數(shù)據流圖，常用的做法是，設想把數(shù)據流圖中的處理進行分組的各種可能的方法，拋棄在技術上行不通、不合理的分組方法，余下的分組方法代表可能的實現(xiàn)策略?？傮w設計的過程（2）選取合理的方案從前一步的到的不同方案中選取若干個合理的方案，通常要包括低成本、中等成本和高成本的”三種方案。在判斷方案的合理性時，可依據可行性研究階段確定的項目規(guī)模，有時可能還需要進一步征求用戶的意見。總體設計的過程（3）推薦最佳方案系統(tǒng)分析員應綜合分析對比各種合理方案的利弊，推薦一個最佳方案，并為此方案制定詳細的實現(xiàn)計劃。用戶”和有關技術專家應認真審查分析員推薦的最佳方案，如果確實符合用戶需求，且在現(xiàn)有技術條件下能夠完全實現(xiàn)，則提請使用部門負責人進行審批。在審批通過后，方可進入總體設計的下一個重要階段——結構設計?？傮w設計的過程（4）功能分級結構設計的任務是確定目標系統(tǒng)由哪些模塊組成，以及這些模塊之間的邏輯關系。結構設計之”后的過程設計屬于詳細設計階段的任務，用于確定每個模塊的處理過程?？傮w設計的過程為了確定軟件的結構，首先應該從實現(xiàn)的角度把復雜的功能進一步分解。具體做法是，仔細分析數(shù)據流圖中的每個處理，如果一個處理的功能”過分復雜，則把它適當?shù)姆纸獬梢幌盗斜容^簡單的功能，整個分解過程實質上是對數(shù)據流圖的進一步細化。在分解的過程中，還應該用IPO表簡要地描述每個處理的算法?？傮w設計的過程（5）設計軟件結構設計軟件結構就是要把軟件的模塊組織成良好的層次系統(tǒng)。在這個層次系統(tǒng)中，每一層模塊都調用它”下一層的模塊，每個下層模塊再調用更下層的模塊，最下層的模塊完成最具體的功能，從而實現(xiàn)程序的某個子功能，所有的子功能共同完成系統(tǒng)的完整功能。描述軟件結構可以使用層次圖或結構圖?？傮w設計的過程如果數(shù)據流圖已經細化到適當?shù)膶哟危ㄈ绻俜纸饩蜕婕暗竭^程設計的問題），則可以”直接從數(shù)據流圖映射出軟件結構。總體設計的過程（6）數(shù)據庫設計對于需要使用數(shù)據庫的應用領域，還要進”行數(shù)據庫設計。數(shù)據庫的設計包括模式設計子模式設計、完整性設計和安全性設計、優(yōu)化處理等?？傮w設計的過程（7）制定測試計劃雖然是在設計階段，但是提早考慮測試問題，能促使設計人員在設計時注意提高軟件的”可測試性。在總體設計階段僅是利用黑盒測試法制定功能測試計劃與測試策略。在詳細設計時才編寫詳細的測試用例和測試計劃。總體設計的過程（8）編寫文檔應該用正式的文檔記錄總體設計的結果，文檔通常包括以下五種。①

系統(tǒng)說明。主要內容包括系統(tǒng)流程圖描繪的系統(tǒng)構成”方案，組成系統(tǒng)的物理元素清單，成本/效益分析，對最佳方案的概括性描述，精華的數(shù)據流圖，用層次圖或結構圖描繪的軟件結構，用IPO表或PDL語言簡要描述的各個模塊的算法，模塊間的結構關系，以及需求、功能和模塊三者之間的交叉參照關系等?？傮w設計的過程②

用戶手冊。根據總體設計的結果，修改更正在需求分析階段產生的初步的用戶手冊。③

測試計劃。包括測試策略、測試方案、預期結”果、測試計劃等。④

詳細的實現(xiàn)計劃。包括實現(xiàn)的各階段所需要的時間、資源、人員配置等。⑤

數(shù)據庫設計的結果?？傮w設計的過程（9）審查和復查最后，應該對總體設計的結果進行嚴格的”技術審查，在通過之后，再由使用部門負責人從管理的角度進行復審?？傮w設計的典型整體過程如圖4.2所示。圖4.2典型總體設計過程總體設計的原理03模塊和模塊化模塊并非是計算機專有術語，在計算機領域也沒有統(tǒng)一的嚴格定義，但是幾乎所有的軟件體系結構都是以模塊為最小單位構建的。模塊也成構件，是指可單獨命名且可通過名字訪問的過程函數(shù)、子程序或宏調用。在具體計算機語言中，模塊是由邊界元素（比如Java中的｛…｝）限定的相鄰程序元素的序列，且有一個總體標識符代表它。面向對象方法學中的對象、對象中的方法，都是模塊。模塊和模塊化模塊一般具有如下四個基本屬性。（1）接口：指模塊的輸入與輸出。（2）功能：指模塊實現(xiàn)的處理。（3）邏輯：描述模塊內部的處理過程。（4）狀態(tài)：指模塊使用時的環(huán)境和條件。模塊化就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，所有模塊按用戶業(yè)務邏輯集成起來構成一個整體，完成指定的功能滿足用戶需求。模塊和模塊化模塊化的目的是為了降低軟件的復雜性。對軟件進行適當?shù)姆纸?，可以減少開發(fā)難度，降低開發(fā)成本，提高考法效率。模塊化的論據如下：如果C(x)表示問題x的復雜程度，函數(shù)E(x)表示解決問題x所需要的工作量函數(shù)。對于p1、p2兩個問題，如果C(p1)>C(p2)，

則有：E(p1)>E(p2)（公式4.1）模塊和模塊化由于p1和p2兩個問題合成一個問題時的復雜程度大于分別考慮每個問題時的復雜程度之和，即C(p1+p2)>C(p1)+C(p2)。這種假設看起來似乎有些武斷，但大多數(shù)情況下的確如此。所以，可以得到：E(p1+p2)>E(p1)+E(p2)

（公式4.2）模塊和模塊化但是如果按照這個論斷，無限制地分割軟件就可以無限地降低成本。現(xiàn)實中顯然并非如此，因為還有另一個因素起作用，使得上述論斷不能成立。當無限地分割軟件時，雖然每個模塊的規(guī)模在減小，開發(fā)成本在降低，但同時系統(tǒng)的總模塊數(shù)會上升，模塊間的接口設計所需要的成本會顯著提升。如圖4.3所示。最小成本區(qū)成本或工作量總成本集成成本M成本/模塊模塊數(shù)量圖4.3模塊化和軟件成本關系圖模塊和模塊化由圖4-3可知，存在一個模塊數(shù)M，使得軟件總成本最低?？梢娫诳傮w設計中，只有選擇合適的模塊數(shù)據，才會使得整個系統(tǒng)的開發(fā)成本較小，但在目前還無法準確預測這個M的數(shù)值。模塊和模塊化采用模塊化原理可以使軟件結構清晰，降低設計難度，提高可理解性。由于程序的錯誤大多發(fā)生在模塊及它們之間的接口中，所以模塊化設計會使軟件容易測試和調試，進而有助于提高軟件的可靠性。當變動僅涉及少數(shù)幾個模塊時，模塊化還能夠提高可修改性。另外，模塊化也有助于軟件開發(fā)的組織管理，一個復雜的大型程序可以通過模塊化分解成許多程序，按照實現(xiàn)的難易度分配給技術熟練水平不同的程序員。抽象抽象是人類認識復雜現(xiàn)象時使用的最有力的思維工具。人們在和現(xiàn)實世界的互動中認識到，現(xiàn)實世界中的事務、狀態(tài)或過程之間總存在著某些共性。把這些共性歸納和概括起來，暫時忽略它們之間的差異，這就是抽象。抽象就是抽出事物的本質特性而暫時不考慮它們的細節(jié)。抽象當考慮任何問題的模塊化解法時，可以提出許多抽象的層次。在抽象的最高層次使用問題環(huán)境的語言，以概括的方式敘述問題的解法。在較低層次上使用更過程化的方法，把面向問題的術語和面向實現(xiàn)的術語結合起來描述問題的解法。最后，在最低的抽象層次則以直接實現(xiàn)的方式敘述問題的解法。抽象軟件工程中的每個步驟都是對軟件解決方案抽象化程度的一次細化。在可行性研究階段，軟件作為系統(tǒng)的一個完整部件；在需求分析階段，軟件解法是使用在問題環(huán)境內熟悉的方式進行的描述；當有總體設計向詳細設計過渡時，抽象的程度也隨之減少了；最后，當源程序寫出來后，也就達到了抽象的最底層。逐步求精逐步求精最初是由NiklausWirth提出的一種自頂向下的設計策略。按照這個策略，程序的體系結構是通過逐步精化處理過程的層次而設計出來的。通過逐步分解對功能的宏觀陳述而開發(fā)出層次結構，最終得出用程序設計語言表達的程序。逐步求精抽象與求精是一對互補的概念。抽象使得設計者能夠說明結構和數(shù)據，但卻同時忽略了底層的細節(jié)。事實上，可以把抽象看作是一種通過忽略多余的細節(jié)同時強調有關的細節(jié)，而實現(xiàn)逐步求精的方法。求精則幫助設計者在設計過程中逐步解釋底層細節(jié)。這兩個概念都有助于設計者在設計演化過程中創(chuàng)造出完整的設計模型。信息隱藏與局部化應用模塊化原理時，必然會產生一個問題：如何分解一個軟件才能得到最佳的模塊組合？1972年，D．Parnas提出的信息隱藏原理指出：每一個模塊的實現(xiàn)細節(jié)（過程和數(shù)據）對于不需要這些信息的其他模塊來說應該是隱藏的。信息隱藏與局部化局部化的概念和信息隱藏概念是密切相關的。所謂局部化是指把一些關系密切的軟件元素物理地放得彼此靠近。局部化實質上是一種實現(xiàn)信息隱藏的手段，信息隱藏是局部化的結果。信息隱藏與局部化信息隱藏意味著有效的模塊化可以通過定義一組獨立的模塊來實現(xiàn)，這些模塊相互間的通信僅使用對于實現(xiàn)軟件功能來說是必要的信息。信息隱藏的原理不僅使得模塊可以進行并行開發(fā)，還可以減少測試和后期維護的工作量。因為測試和維護階段不可避免地要修改設計和代碼，模塊對于多數(shù)數(shù)據和處理過程細節(jié)的隱藏可以減少錯誤向外傳播。此外，整個系統(tǒng)欲擴充功能也只需“插入”新模塊，原有的多數(shù)模塊無需改動。模塊獨立模塊的獨立性是指軟件系統(tǒng)中每個模塊只涉及軟件要求的具體子功能，而和軟件系統(tǒng)中其他的模塊的接口是簡單的。顯然，模塊化、抽象、信息隱藏和局部化的直接結果是模塊獨立。模塊獨立程度可以由兩個定性標準度量：耦合和內聚。耦合衡量不同模塊彼此間的相互依賴程度；內聚衡量一個模塊內部各元素間彼此結合的緊密程度。顯然，模塊的耦合性越低，其獨立性越強，內聚性越高，其獨立性越強。模塊獨立（1）耦合耦合是對一個軟件結構內不同模塊間相互關聯(lián)程度的度量。耦合強弱取決于模塊間接口的復雜程度，一般由模塊之間的調用方式、傳遞信息的類型和數(shù)量來決定。模塊獨立軟件設計，應該追求盡可能松散耦合的結構。這樣的程序容易測試、修改和維護，當某一模塊中出現(xiàn)錯誤時，傳播到整個系統(tǒng)的可能性也小。模塊間的耦合性強烈影響著系統(tǒng)的可理解性、可測試性、可靠性和可維護性。模塊間的耦合方式有六種，如圖4.4所示。低高耦合性低耦合中等強度耦合

較強耦合強耦合非直接耦合

數(shù)據耦合特征耦合

控制耦合

公共環(huán)境耦合

內容耦合模塊獨立性強弱圖4.4耦合性的6種類型模塊獨立①

非直接耦合。如果兩個模塊分別從屬于不同的上級模塊的控制與調用，它們之間不直接傳遞任何信息，互相獨立，則稱這兩個模塊為非直接耦合關系。需要注意的是，在一個軟件系統(tǒng)中，所有模塊之間不可能沒有任何間接的練習，否則，它們無法構成一個系統(tǒng)。模塊獨立②

數(shù)據耦合。如果兩個模塊之間有調用關系，相互以參數(shù)形式傳遞信息，而且交換的信息僅僅是數(shù)據，那么這種耦合稱為數(shù)據耦合。系統(tǒng)中至少必須存在這種耦合，因為只有當某些模塊的輸出數(shù)據作為另一個模塊的輸入數(shù)據時，系統(tǒng)才能完成有價值的功能。數(shù)據耦合是理想的設計目標。模塊獨立③

特征耦合。兩個模塊通過傳遞數(shù)據結構加以聯(lián)系，或都與一個數(shù)據結構有關系，則稱這兩個模塊之間存在特征耦合（或標記耦合）。當被調用模塊只需要整個數(shù)據結構中的一部分數(shù)據元素時，將整個數(shù)據結構作為參數(shù)的弊端是極易造成信息泄漏，給計算機犯罪提供了可乘之機。模塊獨立④

控制耦合。如果兩個模塊彼此間傳遞的信息中有控制信息，這種耦合稱為控制耦合。比如，一個模塊傳遞開關、標志、名字等控制信息，明顯控制另一個模塊的內部執(zhí)行邏輯。這種耦合意味著被調用模塊內部的功能分解不徹底，調用模塊需要知道被調用模塊內部的邏輯結構，這就降低了模塊的獨立性，對被調用模塊再分解后可以用數(shù)據耦合替代。模塊獨立⑤

公共環(huán)境耦合。當兩個或多個模塊通過一個公共數(shù)據環(huán)境相互作用時，它們之間的耦合稱為公共環(huán)境耦合。公共環(huán)境是指全局變量、共享通信區(qū)、內存的公共覆蓋區(qū)、任何存儲介質上的文件、物理設備等。公共環(huán)境耦合的強度，隨耦合的模塊個數(shù)而變化——隨耦合模塊的個數(shù)增加而增加。在只有兩個模塊有公共環(huán)境耦合的情況下，這種耦合又可分為兩種情況。模塊獨立一種情況是，一個模塊往公共環(huán)境送數(shù)據，另一個模塊從公共環(huán)境取數(shù)據。這種公共環(huán)境耦合是一種比較松散的耦合。另一種情況是，兩個模塊都既往公共環(huán)境中送數(shù)據，又從連取數(shù)據。這種耦合比較緊密，介于數(shù)據耦合和控制耦合之間。模塊獨立如果兩個模塊共享的數(shù)據很多，都通過參數(shù)傳遞可能很不方便，此時利用公共環(huán)境耦合是一種可以被接受的方案。模塊獨立⑥

內容耦合。如果一個模塊直接訪問另一個模塊的內部數(shù)據，一個模塊不通過正常入口而轉入到另一個模塊的內部，兩個模塊有一部分代碼重疊（只可能出現(xiàn)在匯編程序中），一個模塊有多個入口，這些現(xiàn)象都屬于內容耦合。內容耦合是最高程度的耦合，是應該堅決避免使用的耦合。模塊獨立總之，在設計軟件結構時，應該根據問題的特點，選擇合適的耦合類型。盡量使用數(shù)據耦合，少用標記耦合和控制耦合，限制使用公共環(huán)境耦合，完全不用內容耦合。具體做法有：降低模塊接口的復雜性，減少每個模塊的參數(shù)個數(shù)，盡量使用標準過程調用，少用直接引用，以標準的形式直接傳遞數(shù)據，把模塊的通信信息放在緩沖區(qū)中。模塊獨立（2）內聚內聚標志了一個模塊內部各元素彼此結合的緊密程度。它是信息隱藏和局部化概念的自然擴展。理想的內聚是每個模塊只做一件事。設計軟件結構時應該力求做到高內聚，中等程度的內聚也是可以接受的選擇。內聚和耦合密切相關，內聚高往往意味著耦合松散。模塊獨立內聚和耦合都是設計軟件結構時需要考慮的結構特征，但是實踐經驗表明，內聚更重要，應該把更多的注意力集中到提高模塊的內聚程度上。這類似于每個人做好自己，最終形成良好社會的的價值觀，因為通過統(tǒng)籌管理獲得全面提高的難度顯然更大。按照內聚程度的不同，內聚可以分為七種情況，如圖4.5所示。低高內聚性中等強度內聚低內聚強內聚偶然內聚邏輯內聚時間內聚過程內聚通信內聚順序內聚功能內聚模塊獨立性強弱圖4.5內聚類型模塊獨立①

偶然內聚。模塊內個元素之間沒有實質性的聯(lián)系，或者說模塊內各組成成分在功能上互不相關。偶然內聚是強度最低的一種內聚，模塊內各元素不是為同一個功能服務，各有不同需求，因而模塊的內容不易理解，也不易修改和維護。模塊獨立②

邏輯內聚。如果一個模塊完成的任務在邏輯上屬于相同或相似的一類，各元素之間存在必然的邏輯關系，則它們之間的關系屬于邏輯內聚。典型的情況是把幾種相關的功能組合在一個模塊內，由傳遞給模塊的參數(shù)確定每次調用執(zhí)行哪種功能。邏輯內聚會存在不同功能混在一起，共用部分程序代碼的情況，在遇到需求修改模塊時，往往會影響全局，使修改比較困看。模塊獨立③

時間內聚。一個模塊包含的任務必須在同一時間段內執(zhí)行，這些功能僅是因為時間因素被組織在一起。例如，初始化工作，同時打開文件，關閉文件，緊急故障處理等都是時間內聚模塊。一般情況下，各部分只要滿足時間上的同一性，執(zhí)行順序可以任意安排。模塊獨立④

過程內聚。如果一個模塊內的元素是相關的，而且必須以特定次序執(zhí)行，受同一控制流支配則稱為過程內聚。使用程序流程圖設計程序時，確定的模塊劃分往往得到過程內聚的模塊。例如，把流程圖中的循環(huán)部分、判定部分、計算部分分成3個模塊，這3個模塊是過程內聚模塊。模塊獨立⑤

通信內聚。如果模塊中所有元素都使用相同的輸入數(shù)據或產生相同的輸出數(shù)據，則稱為通信內聚。⑥

順序內聚。如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執(zhí)行。通常是，一個處理元素的輸出最為下一個處理元素的輸入，即在同一個數(shù)據結構上操作。根據數(shù)據流圖劃分模塊時，往往得到順序內聚的模塊。模塊獨立⑦

功能內聚。模塊內的所有處理元素屬于一個整體，即完成一個單一的功能。功能內聚是最高成都的內聚，是設計的目標和理想的結構。在實際設計中，沒有必要精確確定內聚的級別，重要的是力爭做到高內聚，并且能辨認出低內聚模塊，通過修改結構提高內聚程度。軟件結構設計準則04軟件結構設計準則人們在軟件開發(fā)的長期實踐中積累了豐富的經驗，總結得出了一些啟發(fā)規(guī)則，這些規(guī)則不是普適的基本原理，但是在許多場合仍然具有一定的指導作用，往往能幫助設計人員改進軟件結構提高軟件質量。這些規(guī)則不是設計目標，但可以作為軟件結構設計的準則加以利用。這些準則如下：軟件結構設計準則（1）改進軟件結構提高模塊獨立性。初步設計出軟件結構之后，為了提高模塊的獨立性，應該審查、分析這個結構，通過分解和合并，力求降低耦合性提高內聚性。例如多個模塊公有的一個子功能可以獨立成一個模塊，由這些模塊調用；有時通過分解或合并模塊可以減少控制信息的傳遞及對全程數(shù)據的引用，并降低接口的復雜程度。軟件結構設計準則（2）模塊規(guī)模應該適中。有人從心理學角度研究得知，一個模塊的規(guī)模不應過大，最好能寫在一頁A4紙內（通常不超過60行語句），當超過30行以后，模塊的可理解性迅速下降。過大的模塊往往是由于分解不充分，但是進一步分解必須符合問題結構，一般說，分解不應以犧牲模塊獨立性為代價。軟件結構設計準則模塊規(guī)模也不宜過小，模塊過小，目標系統(tǒng)所需的模塊個數(shù)必然增多，接口必然復雜。特別是只有一個上層模塊調用的模塊，通常可以合并到上級模塊中。軟件結構設計準則（3）深度、寬度、扇入、扇出都應當適中深度指軟件結構中控制的層數(shù)。在一定意義上能粗略地反映系統(tǒng)的規(guī)模和復雜程度。深度和程序的長度有粗略的對應關系，程序越長往往容易深度越深。如果深度過大，則表示控制層數(shù)太多，應該考慮是否其中某些模塊分的過于簡單了，可以考慮適當合并。軟件結構設計準則寬度是指軟件結構在同一個層次上的模塊總數(shù)的最大值。一般說來，寬度越大系統(tǒng)越復雜。對寬度影響最大的因素是模塊的扇出。扇出是指一個模塊直接調用的模塊數(shù)目。扇出過大意味著模塊過分復雜，需要協(xié)調和控制過多的下層模塊；扇出過小也不好，比如總數(shù)是1。經驗表明，一個設計得好的典型系統(tǒng)的平均扇出通常是3或4（扇出的上限通常是5~9）。軟件結構設計準則扇出過大一般是因為缺乏中間層，此時應當適當增加中間控制層模塊。扇出過小時，可以把下級模塊進一步分解成若干個子功能模塊，或者合并到上級模塊中去。通過分解或合并調整軟件結構時，必須符合問題結構（即不能違背解決問題的常識），同時也不能違背模塊獨立原理。軟件結構設計準則扇入是指一個模塊有多少個上級模塊直接調用它。扇入越大說明該模塊共享程度越高，這是有利的，但是，不能違背模塊獨立原理單純追求高扇入。一般設計得好的軟件結構，通常頂層扇出比較高，中間層扇出較少，底層扇入到公共的使用模塊中區(qū)，從形象看像一個橄欖型。軟件結構設計準則（4）模塊的作用域應該在控制域之內模塊的作用域是指受該模塊內一個判定影響的所有模塊的集合。模塊的控制域是指模塊本身及其所有直接或間接從屬于它的模塊集合。軟件結構設計準則在一個設計得好的系統(tǒng)中，所有受判定影響的模塊應該都從屬于做出判定的那個模塊，最好局限于做出判定的那個模塊本身及它的下屬模塊。否則，就需要在作用域之外傳遞控制信息，以保持判定應有的作用，如此便增加了控制耦合，使軟件結構變得復雜而難以理解。軟件結構設計準則（5）降低模塊結構的復雜程度模塊接口復雜是軟件出錯的主要原因之一。接口的設計應該盡量使信息傳遞簡單，并與模塊的功能一致。如果模塊的接口復雜或不一致（即看起來傳遞的數(shù)據之間沒有聯(lián)系），是緊耦合低內聚的征兆，應該重新分析該模塊的獨立性。軟件結構設計準則（6）設計單入口單出口的模塊這條規(guī)則是在告誡軟件工程師不要模塊間出現(xiàn)內容耦合。當從頂部進入模塊且從底部退出模塊時，軟件是比較容易理解的。軟件結構設計準則（7）模塊功能應該可以預測模塊功能應該能夠預測，是考慮到方便以后的軟件測試性和維護，但也要防止模塊功能過分局限。軟件結構設計準則如果一個模塊可以看作一個黑盒子，只要輸入相同的數(shù)據就產生同樣的輸出，這個模塊的功能就是可以預測的。任意限制模塊內數(shù)據結構的大小、過分限制在控制流中可以做出的選擇或外部接口的模式，該模塊的功能就過分局限了（使用范圍過分狹窄），畢竟可重用性是現(xiàn)代軟件設計追求的價值觀之一。在現(xiàn)實中不可避免地要修改這類結構，以提高模塊的靈活性，擴大它的使用范圍。軟件結構設計準則以上七條總體設計的準則是經驗性的，對改進設計、提高質量往往具有重要的參考價值。但是，需要注意它們既不是設計的目標，也不是設計時應該普遍遵循的原理，僅是可以借鑒的經驗。描繪軟件結構的圖形工具05層次圖層次圖用來描繪軟件的層次結構。層次圖中，一個矩形框代表一個模塊，方框間的連線表示調用關系，最頂層的方框代表目標系統(tǒng)的主控模塊。在方框圖中，位于上層的模塊調用其有連線的下層模塊。層次圖適用于自頂向下設計軟件結構。圖4.6是一個庫存管理系統(tǒng)的層次圖。層次圖在使用層次圖時，應該注意以下三點。（1）在層次圖中，同一層模塊對其上層來說，不存在調用次序問題，雖然人們習慣于從左往右畫，但并不代表系統(tǒng)按此順序調用下層模塊。（2）層次圖不指明怎樣調用模塊。（3）層次圖只表明一個模塊調用哪些模塊。HIPO圖HIPO（Hierarchy

Plus

Input-Process-Output）圖是層次圖加上輸入-處理-輸出圖的英文縮寫，是IBM公司20世界70年代發(fā)展起來表示軟件結構的一種常用描述工具。為了能使HIPO圖具有可追蹤性，在H圖（層次圖）中除了頂層方框之外，每個方框都加了編號。HIPO圖完整的HIPO圖由層次圖和IPO表組成。H圖中的每一個模塊要對應一張IPO表，每一個IPO表都要編號，并且要和它所對應的模塊的編號一致。結構圖Yourdon提出的結構圖是進行軟件結構設計的另一個有力工具。結構圖中一個方框代表一個模塊，框內注明模塊的名稱或主要功能；方框之間用箭頭或直線連接表示調用關系，因為按照習慣總是上方模塊調用下層模塊，為了簡單起見，一般用直線替代箭頭線表示模塊間的調用關系。結構圖在結構圖中通常還用帶有注釋的箭頭表示模塊調用過程中來回傳遞的信息，其中箭頭尾部是空心圓表示傳遞的是數(shù)據，實心圓表示傳遞的是控制信息，如圖4.8所示。產生最佳解結構圖解得到好輸入計算最佳解輸出結果結果格式化顯示結果讀輸入編輯輸入圖4.8產生最佳解的結構圖此外，結構圖還使用一些附加符號表示模塊的選擇調用或循環(huán)調用。圖4.9所示為當模塊M中某個判定為真時調用模塊A，為假時調用模塊B。圖4.10所示為模塊M循環(huán)調用A、B、C。圖4.9結構圖選擇調用表示法圖4.10結構圖循環(huán)調用表示法結構圖通常層次圖作為描繪軟件結構的文檔，而結構圖作為文檔并不是很合適，因為結構圖上的信息較多，反而降低了結構圖的清晰性。但是，結構圖卻可以作為檢查設計正確性和評價模塊獨立性的好方法。如果發(fā)現(xiàn)結構圖上的模塊間的練習不容易解釋，則應該考慮是否設計上存在問題。面向數(shù)據流的軟件結構設計方法06面向數(shù)據流的軟件結構設計方法面向數(shù)據流的軟件結構設計方法，即以數(shù)據流圖為依據的設計軟件結構的方法，也是通常所說的結構化設計方法（簡稱SD方法）。因為任何軟件系統(tǒng)都可以用數(shù)據流圖表示，所以面向數(shù)據流的設計方法理論上可以設計任何軟件系統(tǒng)的結構。概念面向數(shù)據流的設計方法的實質是把數(shù)據流圖的信息流映射成軟件結構。因此，信息流的類型決定了映射的方法。按照信息流的流動特征，可以分為變換流和事務流。概念（1）變換流任何軟件系統(tǒng)都看作是一種信息處理系統(tǒng)，信息通常以“外部世界”的形式進入系統(tǒng)，經過處理再以“外部世界”的形式離開系統(tǒng)。概念變換流的特征如圖4.11所示。信息沿輸入通路進入系統(tǒng)，同時由外部形式轉換成內部形式，進入系統(tǒng)的信息經過變換中心的加工處理后，再沿著輸出通路變換成外部形式離開軟件系統(tǒng)。當數(shù)據流具有這些特征時，這種信息流就叫做變換流。概念（2）事務流基本系統(tǒng)模型的實質是變換流，因此，原則上所有信息流都可歸結為變換流。但是，當數(shù)據流圖明顯具有圖4.12特征時，這種數(shù)據流是“以事務為中心的”，即數(shù)據沿著輸入通路到達一個處理T，該處理根據輸入數(shù)據的類型在若干個動作序列中選出一個執(zhí)行。這種數(shù)據流稱為事務流（輸入數(shù)據稱為事務）。圖4.11變換流示意圖圖4.12事務流示意圖面向數(shù)據流設計方法的過程運用面向數(shù)據流的方法進行軟件結構設計的過程，如圖4.13所示。應該注意，設計屬于創(chuàng)造性活動，不能沒有規(guī)矩，但更不能拘囿于規(guī)矩，設計首先需要人的判斷力和創(chuàng)造精神，這些常常需要凌駕于規(guī)則之上，才能有最大自由的發(fā)揮，才能獲得最佳的效果。圖面向數(shù)據流設計方法的過程變換分析法（1）復查基本系統(tǒng)模型首先應該對需求分析階段得到的基本系統(tǒng)模型進行復查，復查的目的是為了確保輸入數(shù)據和輸出數(shù)據符合實際。變換分析法（2）復查并精化數(shù)據流圖應該對需求分析階段得到的數(shù)據流圖進行復查，并在必要時進行精化。要確保數(shù)據流圖正確描繪了目標系統(tǒng)的業(yè)務業(yè)務邏輯，同時要確保數(shù)據流圖中的每個處理都代表了一個規(guī)模適中、相對獨立的子功能。變換分析法（3）確定數(shù)據流圖的類型通常，一個系統(tǒng)中的所有信息都可以被認為是變換流，但是，當遇到有明顯事務特性的信息流時，還是采用事務分析的方法進行映射。多數(shù)情況是，系統(tǒng)即具有變換特征，也具有事務特征，因此，在確定系統(tǒng)數(shù)據流圖的特征時，應該從全局角度考慮哪種特征更占優(yōu)。變換分析法（4）確定數(shù)據流的邊界對于變換流來說，分析確定輸入流和輸出流的邊界，從而孤立出變換中心。對于事務流來說，分析確定輸入流的邊界，從而孤立出事務中心。變換分析法在確定邊界時，不同的設計考慮有不同的取舍標準，但是，通常一個處理框的誤差對最終的軟件結構影響不大，況且在到初步軟件結構后，還有優(yōu)化調整的要求。接下來，選取相應的分析方法把系統(tǒng)數(shù)據流圖映射成變換型結構或事務型結構。變換分析法（5）完成“第一級分解”傳統(tǒng)方法論中，軟件結構代表對控制自頂向下的分配，所謂分解其實就是分配控制，分配從屬關系。第一級分解，就是分配軟件結構中的頂層控制。變換分析法對于變換流的情況，位于軟件結構最頂層的總控模塊協(xié)調以下三個從屬模塊的控制。（1）輸入信息處理控制模塊。此模塊協(xié)調對所有輸入數(shù)據的接收。（2）變換中心控制模塊。此模塊管理對內部形式的數(shù)據的所有操作。（3）輸出信息處理控制模塊。此模塊協(xié)調輸出信息的產生過程。變換分析法（6）完成“第二級分解”進行第二級分解就是把數(shù)據流圖中的每個處理映射成軟件結構中的一個適當?shù)哪K。具體到變換流來說，第二級分解就是從變換中心的邊界開始沿著輸入通路向外移動，把輸入通路中每個處理依次映射成軟件結構中的“輸入信息處理控制模塊”控制下的一個低層模塊。變換分析法然后，再從變換中心的邊界開始，沿著輸出通絡向外移動，把輸出通路中的每個處理依次映射成直接或間接受“輸出信息處理控制模塊”控制的一個低層模塊。最后，把變換中心內的每個處理映射成受“變換中心控制模塊“控制的一個個模塊。變換分析法（7）優(yōu)化對經過以上步驟得到的結果按照模塊獨立原理和總體設計準則進行優(yōu)化。為了產生合理的分解，得到盡可能高的內聚、盡可能松散的耦合，最重要的是得到一個易于實現(xiàn)、易于測試、和易于維護的軟件結構，應該對初步得到的軟件模塊進行再分解或合并。變換分析法機械地遵循上述映射規(guī)則很可能會得出一些不必要的控制模塊，如果它們確實用處不大，那么應該合并它們。如果控制模塊功能過分復雜，可以適當?shù)卦黾又虚g層的控制模塊或者進一步將它們分解。變換分析法任何優(yōu)化過程不能違背設計原理，不能違背問題域常識、不能為了最求所謂的“最佳設計”而優(yōu)化。設計的優(yōu)化可能會導出不同的軟件結構，要從中選優(yōu)，力求得到“最好“的結構。避免把結構的優(yōu)化留到過程設計階段，這也是把結構設計和過程設計分開的價值所在。變換分析法結構簡單往往表明效率高。設計優(yōu)化應該力求做到在有效模塊化的前提下使用盡可能少的模塊數(shù)，以及在能夠滿足信息要求的前提下使用最簡單的數(shù)據結構。切記，不能正常工作的最佳設計沒有實際意義。正常工作是一切設計優(yōu)化的基礎，高效、最佳只是愿景目標。簡單說就是“先使它能工作，然后再使它快起來”。事務分析法事務分析的設計步驟和變換分析的設計步驟大致相同或類似，區(qū)別僅在于映射方法。由事務流映射成的軟件結構包括一個接收分支和一個發(fā)送分支。從事務中心的邊界開始，把接收流童虎的處理映射成模塊。發(fā)送分支由一個調度模塊控制它下面的所有模塊。然后把數(shù)據流圖中的每個活動流通路映射成與它的流特征相對應的結構。如圖4.14所示?？偪亟邮胀氛{度BACA通

路圖4.14事務分析映射法事務分析法一般來說，如果數(shù)據流圖不具有顯著的事務特征，最好使用變換分析；反之，則使用事務分析技術。對于大型的或復雜的系統(tǒng)，事務分析和變換分析往往兼而有之。事務分析法例4.1：由于總體設計的主要工作開始于對需求分析獲得的數(shù)據流圖的分析，下面以某個“學生檔案管理系統(tǒng)”的數(shù)據流圖為例，運用面向數(shù)據流的方法設計其軟件結構。假設某“學生檔案管理系統(tǒng)”的數(shù)據流圖如圖4.15所示，并且假設