總體設計概要設計

《總體設計概要設計》由會員分享，可在線閱讀，更多相關《總體設計概要設計（109頁珍藏版）》請在裝配圖網上搜索。

1、第 5章 總 體 設 計5.1 設計過程5.2 設計原理5.3 啟發(fā)規(guī)則5.4 描繪軟件結構的圖形工具5.5 面向數據流的設計方法5.6 小結習題 總體設計的基本目的就是回答“概括地說，系統(tǒng)應該如何實現?”這個問題，因此，總體設計又稱為概要設計或初步設計。通過這個階段的工作將劃分出組成系統(tǒng)的物理元素程序、文件、數據庫、人工過程和文檔等等，但是每個物理元素仍然處于黑盒子級，這些黑盒子里的具體內容將在以后仔細設計?？傮w設計階段的另一項重要任務是設計軟件的結構，也就是要確定系統(tǒng)中每個程序是由哪些模塊組成的，以及這些模塊相互間的關系。 總體設計過程首先尋找實現目標系統(tǒng)的各種不同的方案，需求分析階段得到

2、的數據流圖是設想各種可能方案的基礎。然后分析員從這些供選擇的方案中選取若干個合理的方案，為每個合理的方案都準備一份系統(tǒng)流程圖，列出組成系統(tǒng)的所有物理元素，進行成本/效益分析，并且制定實現這個方案的進度計劃。分析員應該綜合分析比較這些合理的方案，從中選出一個最佳方案向用戶和使用部門負責人推薦。如果用戶和使用部門的負責人接受了推薦的方案，分析員應該進一步為這個最佳方案設計軟件結構，通常，設計出初步的軟件結構后還要多方改進，從而得到更合理的結構，進行必要的數據庫設計，確定測試要求并且制定測試計劃。 從上面的敘述中不難看出，在詳細設計之前先進行總體設計的必要性：可以站在全局高度上，花較少成本，從較抽象

3、的層次上分析對比多種可能的系統(tǒng)實現方案和軟件結構，從中選出最佳方案和最合理的軟件結構，從而用較低成本開發(fā)出較高質量的軟件系統(tǒng)。 總體設計過程通常由兩個主要階段組成：系統(tǒng)設計階段，確定系統(tǒng)的具體實現方案；結構設計階段，確定軟件結構。典型的總體設計過程包括下述9個步驟：1. 設想供選擇的方案在總體設計階段分析員應該考慮各種可能的實現方案，并且力求從中選出最佳方案。在總體設計階段開始時只有系統(tǒng)的邏輯模型，分析員有充分的自由分析比較不同的物理實現方案，一旦選出了最佳的方案，將能大大提高系統(tǒng)的性能/價格比。5.1 設計過程 需求分析階段得出的數據流圖是總體設計的極好的出發(fā)點。設想供選擇的方案的一種常用的

4、方法是，設想把數據流圖中的處理分組的各種可能的方法，拋棄在技術上行不通的分組方法(例如，組內不同處理的執(zhí)行時間不相容)，余下的分組方法代表可能的實現策略，并且可以啟示供選擇的物理系統(tǒng)。 2. 選取合理的方案應該從前一步得到的一系列供選擇的方案中選取若干個合理的方案，通常至少選取低成本、中等成本和高成本的三種方案。在判斷哪些方案合理時應該考慮在問題定義和可行性研究階段確定的工程規(guī)模和目標，有時可能還需要進一步征求用戶的意見。對每個合理的方案分析員都應該準備下列4份資料：(1) 系統(tǒng)流程圖；(2) 組成系統(tǒng)的物理元素清單；(3) 成本/效益分析；(4) 實現這個系統(tǒng)的進度計劃。 3. 推薦最佳方案

5、分析員應該綜合分析對比各種合理方案的利弊，推薦一個最佳的方案，并且為推薦的方案制定詳細的實現計劃。制定詳細實現計劃的關鍵技術是本書第13章中將要介紹的工程網絡。用戶和有關的技術專家應該認真審查分析員所推薦的最佳系統(tǒng)，如果該系統(tǒng)確實符合用戶的需要，并且是在現有條件下完全能夠實現的，則應該提請使用部門負責人進一步審批。在使用部門的負責人也接受了分析員所推薦的方案之后，將進入總體設計過程的下一個重要階段結構設計。 4. 功能分解為了最終實現目標系統(tǒng)，必須設計出組成這個系統(tǒng)的所有程序和文件(或數據庫)。對程序(特別是復雜的大型程序)的設計，通常分為兩個階段完成：首先進行結構設計，然后進行過程設計。結構

6、設計確定程序由哪些模塊組成，以及這些模塊之間的關系；過程設計確定每個模塊的處理過程。結構設計是總體設計階段的任務，過程設計是詳細設計階段的任務。 為確定軟件結構，首先需要從實現角度把復雜的功能進一步分解。分析員結合算法描述仔細分析數據流圖中的每個處理，如果一個處理的功能過分復雜，必須把它的功能適當地分解成一系列比較簡單的功能。一般說來，經過分解之后應該使每個功能對大多數程序員而言都是明顯易懂的。功能分解導致數據流圖的進一步細化，同時還應該用IPO圖或其他適當的工具簡要描述細化后每個處理的算法。 5. 設計軟件結構通常程序中的一個模塊完成一個適當的子功能。應該把模塊組織成良好的層次系統(tǒng)，頂層模塊

7、調用它的下層模塊以實現程序的完整功能，每個下層模塊再調用更下層的模塊，從而完成程序的一個子功能，最下層的模塊完成最具體的功能。軟件結構(即由模塊組成的層次系統(tǒng))可以用層次圖或結構圖來描繪，第5.4節(jié)將介紹這些圖形工具。如果數據流圖已經細化到適當的層次，則可以直接從數據流圖映射出軟件結構，這就是第5.5節(jié)中將要講述的面向數據流的設計方法。 6. 設計數據庫對于需要使用數據庫的那些應用系統(tǒng)，軟件工程師應該在需求分析階段所確定的系統(tǒng)數據需求的基礎上，進一步設計數據庫。在數據庫課中已經詳細講述了設計數據庫的方法，本書不再贅述。7. 制定測試計劃在軟件開發(fā)的早期階段考慮測試問題，能促使軟件設計人員在設計

8、時注意提高軟件的可測試性。本書第7章將仔細討論軟件測試的目的和設計測試方案的各種技術方法。 8. 書寫文檔應該用正式的文檔記錄總體設計的結果，在這個階段應該完成的文檔通常有下述幾種：(1) 系統(tǒng)說明主要內容包括用系統(tǒng)流程圖描繪的系統(tǒng)構成方案，組成系統(tǒng)的物理元素清單，成本/效益分析；對最佳方案的概括描述，精化的數據流圖，用層次圖或結構圖描繪的軟件結構，用IPO圖或其他工具(例如，PDL語言)簡要描述的各個模塊的算法，模塊間的接口關系，以及需求、功能和模塊三者之間的交叉參照關系等等。(2) 用戶手冊根據總體設計階段的結果，修改更正在需求分析階段產生的初步的用戶手冊。 (3) 測試計劃包括測試策略，

9、測試方案，預期的測試結果，測試進度計劃等等。(4) 詳細的實現計劃(5) 數據庫設計結果9. 審查和復審最后應該對總體設計的結果進行嚴格的技術審查，在技術審查通過之后再由使用部門的負責人從管理角度進行復審。 模塊是由邊界元素限定的相鄰程序元素（例如，數據說明，可執(zhí)行的語句）的序列，而且有一個總體標識符代表它。按照模塊的定義，過程、函數、子程序和宏等，都可作為模塊。面向對象方法學中的對象是模塊，對象內的方法（或稱為服務）也是模塊。模塊是構成程序的基本構件。5.2 設計原理 5.2.1 模塊化 模塊化就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體

10、，可以完成指定的功能滿足用戶的需求。有人說，模塊化是為了使一個復雜的大型程序能被人的智力所管理，軟件應該具備的惟一屬性。如果一個大型程序僅由一個模塊組成，它將很難被人所理解。下面根據人類解決問題的一般規(guī)律，論證上面的結論。設函數C(x)定義問題x的復雜程度，函數E(x)確定解決問題x需要的工作量(時間)。對于兩個問題P1和P2，如果C(P1)C(P2) 顯然E(P1)E(P2)根據人類解決一般問題的經驗，另一個有趣的規(guī)律是C(P1+P2)C(P1)+C(P2)也就是說，如果一個問題由P1和P2兩個問題組合而成，那么它的復雜程度大于分別考慮每個問題時的復雜程度之和。綜上所述，得到下面的不等式E(

11、P1+P2)E(P1)+E(P2)這個不等式導致“各個擊破”的結論把復雜的問題分解成許多容易解決的小問題，原來的問題也就容易解決了。這就是模塊化的根據。 由上面的不等式似乎還能得出下述結論：如果無限地分割軟件，最后為了開發(fā)軟件而需要的工作量也就小得可以忽略了。事實上，還有另一個因素在起作用，從而使得上述結論不能成立。參看圖5.1，當模塊數目增加時每個模塊的規(guī)模將減小，開發(fā)單個模塊需要的成本(工作量)確實減少了；但是，隨著模塊數目增加，設計模塊間接口所需要的工作量也將增加。根據這兩個因素，得出了圖中的總成本曲線。每個程序都相應地有一個最適當的模塊數目M，使得系統(tǒng)的開發(fā)成本最小。 圖5.1 模塊化

12、和軟件成本 雖然目前還不能精確地決定M的數值，但是在考慮模塊化的時候總成本曲線確實是有用的指南。采用模塊化原理可以使軟件結構清晰，不僅容易設計也容易閱讀和理解。因為程序錯誤通常局限在有關的模塊及它們之間的接口中，所以模塊化使軟件容易測試和調試，因而有助于提高軟件的可靠性。因為變動往往只涉及少數幾個模塊，所以模塊化能夠提高軟件的可修改性。模塊化也有助于軟件開發(fā)工程的組織管理，一個復雜的大型程序可以由許多程序員分工編寫不同的模塊，并且可以進一步分配技術熟練的程序員編寫困難的模塊。 人類在認識復雜現象的過程中使用的最強有力的思維工具是抽象。人們在實踐中認識到，在現實世界中一定事物、狀態(tài)或過程之間總存

13、在著某些相似的方面(共性)。把這些相似的方面集中和概括起來，暫時忽略它們之間的差異，這就是抽象?；蛘哒f抽象就是抽出事物的本質特性而暫時不考慮它們的細節(jié)。5.2.2 抽象 由于人類思維能力的限制，如果每次面臨的因素太多，是不可能做出精確思維的。處理復雜系統(tǒng)的惟一有效的方法是用層次的方式構造和分析它。一個復雜的動態(tài)系統(tǒng)首先可以用一些高級的抽象概念構造和理解，這些高級概念又可以用一些較低級的概念構造和理解，如此進行下去，直至最低層次的具體元素。這種層次的思維和解題方式必須反映在定義動態(tài)系統(tǒng)的程序結構之中，每級的一個概念將以某種方式對應于程序的一組成分。 考慮對任何問題的模塊化解法時，可以提出許多抽象

14、的層次。在抽象的最高層次使用問題環(huán)境的語言，以概括的方式敘述問題的解法；在較低抽象層次采用更過程化的方法，把面向問題的術語和面向實現的術語結合起來敘述問題的解法；最后在最低的抽象層次用可直接實現的方式敘述問題的解法。軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。在可行性研究階段，軟件作為系統(tǒng)的一個完整部件；在需求分析期間，軟件解法是使用在問題環(huán)境內熟悉的方式描述的；當由總體設計向詳細設計過渡時，抽象的程度也就隨之減少了；最后，當源程序寫出來以后，也就達到了抽象的最低層。 逐步求精和模塊化的概念，與抽象是緊密相關的。隨著軟件開發(fā)工程的進展，在軟件結構每一層中的模塊，表示了對軟件抽象層次

15、的一次精化。事實上，軟件結構頂層的模塊，控制了系統(tǒng)的主要功能并且影響全局；在軟件結構底層的模塊，完成對數據的一個具體處理，用自頂向下由抽象到具體的方式分配控制，簡化了軟件的設計和實現，提高了軟件的可理解性和可測試性，并且使軟件更容易維護。 逐步求精是人類解決復雜問題時采用的基本方法，也是許多軟件工程技術（例如，規(guī)格說明技術，設計和實現技術）的基礎?？梢园阎鸩角缶x為：“為了能集中精力解決主要問題而盡量推遲對問題細節(jié)的考慮。”逐步求精之所以如此重要，是因為人類的認知過程遵守Miller法則：一個人在任何時候都只能把注意力集中在（72）個知識塊上。5.2.3 逐步求精 但是，在開發(fā)軟件的過程中，

16、軟件工程師在一段時間內需要考慮的知識塊數遠遠多于7。例如，一個程序通常不止使用7個數據，一個用戶也往往有不止7個方面的需求。逐步求精方法的強大作用就在于，它能幫助軟件工程師把精力集中在與當前開發(fā)階段最相關的那些方面上，而忽略那些對整體解決方案來說雖然是必要的，然而目前還不需要考慮的細節(jié)，這些細節(jié)將留到以后再考慮。Miller法則是人類智力的基本局限，我們不可能戰(zhàn)勝自己的自然本性，只能接受這個事實，承認自身的局限性，并在這個前提下盡我們的最大努力工作。 事實上，可以把逐步求精看作是一項把一個時期內必須解決的種種問題按優(yōu)先級排序的技術。逐步求精方法確保每個問題都將被解決，而且每個問題都將在適當的時

17、候被解決，但是，在任何時候一個人都不需要同時處理7個以上知識塊。逐步求精最初是由Niklaus Wirth提出的一種自頂向下的設計策略。按照這種設計策略，程序的體系結構是通過逐步精化處理過程的層次而設計出來的。通過逐步分解對功能的宏觀陳述而開發(fā)出層次結構，直至最終得出用程序設計語言表達的程序。Wirth本人對逐步求精策略曾做過如下的概括說明： “我們對付復雜問題的最重要的辦法是抽象，因此，對一個復雜的問題不應該立刻用計算機指令、數字和邏輯符號來表示，而應該用較自然的抽象語句來表示，從而得出抽象程序。抽象程序對抽象的數據進行某些特定的運算并用某些合適的記號（可能是自然語言）來表示。對抽象程序做進

18、一步的分解，并進入下一個抽象層次，這樣的精細化過程一直進行下去，直到程序能被計算機接受為止。這時的程序可能是用某種高級語言或機器指令書寫的?！?求精實際上是細化過程。我們從在高抽象級別定義的功能陳述（或信息描述）開始，也就是說，該陳述僅僅概念性地描述了功能或信息，但是并沒有提供功能的內部工作情況或信息的內部結構。求精要求設計者細化原始陳述，隨著每個后續(xù)求精（即細化）步驟的完成而提供越來越多的細節(jié)。抽象與求精是一對互補的概念。抽象使得設計者能夠說明過程和數據，同時卻忽略低層細節(jié)。事實上，可以把抽象看作是一種通過忽略多余的細節(jié)同時強調有關的細節(jié)，而實現逐步求精的方法。求精則幫助設計者在設計過程中逐

19、步揭示出低層細節(jié)。這兩個概念都有助于設計者在設計演化過程中創(chuàng)造出完整的設計模型。 應用模塊化原理時，自然會產生的一個問題是：“為了得到最好的一組模塊，應該怎樣分解軟件呢?”信息隱藏原理指出：應該這樣設計和確定模塊，使得一個模塊內包含的信息(過程和數據)對于不需要這些信息的模塊來說，是不能訪問的。局部化的概念和信息隱藏概念是密切相關的。所謂局部化是指把一些關系密切的軟件元素物理地放得彼此靠近。在模塊中使用局部數據元素是局部化的一個例子。顯然，局部化有助于實現信息隱藏。5.2.4 信息隱藏和局部化 實際上，應該隱藏的不是有關模塊的一切信息，而是模塊的實現細節(jié)。因此，有人主張把這條原理稱為“細節(jié)隱藏

20、”。“隱藏”意味著有效的模塊化可以通過定義一組獨立的模塊而實現，這些獨立的模塊彼此間僅僅交換那些為了完成系統(tǒng)功能而必須交換的信息。如果在測試期間和以后的軟件維護期間需要修改軟件，那么使用信息隱藏原理作為模塊化系統(tǒng)設計的標準就會帶來極大好處。因為絕大多數數據和過程對于軟件的其他部分而言是隱藏的(也就是“看”不見的)，在修改期間由于疏忽而引入的錯誤就很少可能傳播到軟件的其他部分。 模塊獨立的概念是模塊化、抽象、信息隱藏和局部化概念的直接結果。開發(fā)具有獨立功能而且和其他模塊之間沒有過多的相互作用的模塊，就可以做到模塊獨立。換句話說，希望這樣設計軟件結構，使得每個模塊完成一個相對獨立的特定子功能，并且

21、和其他模塊之間的關系很簡單。5.2.5 模塊獨立 為什么模塊的獨立性很重要呢?主要有兩條理由：第一，有效的模塊化(即具有獨立的模塊)的軟件比較容易開發(fā)出來。這是由于能夠分割功能而且接口可以簡化，當許多人分工合作開發(fā)同一個軟件時，這個優(yōu)點尤其重要。第二，獨立的模塊比較容易測試和維護。這是因為相對說來，修改設計和程序需要的工作量比較小，錯誤傳播范圍小，需要擴充功能時能夠“插入”模塊?？傊K獨立是好設計的關鍵，而設計又是決定軟件質量的關鍵環(huán)節(jié)。 模塊的獨立程度可以由兩個定性標準度量，這兩個標準分別稱為內聚和耦合。耦合衡量不同模塊彼此間互相依賴(連接)的緊密程度；內聚衡量一個模塊內部各個元素彼此結

22、合的緊密程度。以下分別詳細闡述。1. 耦合耦合是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。 在軟件設計中應該追求盡可能松散耦合的系統(tǒng)。在這樣的系統(tǒng)中可以研究、測試或維護任何一個模塊，而不需要對系統(tǒng)的其他模塊有很多了解。此外，由于模塊間聯(lián)系簡單，發(fā)生在一處的錯誤傳播到整個系統(tǒng)的可能性就很小。因此，模塊間的耦合程度強烈影響系統(tǒng)的可理解性、可測試性、可靠性和可維護性。如果兩個模塊中的每一個都能獨立地工作而不需要另一個模塊的存在，那么它們彼此完全獨立，這意味著模塊間無任何連接，耦合程度最低。但是，在一個軟件系統(tǒng)中不可能所

23、有模塊之間都沒有任何連接。 如果兩個模塊彼此間通過參數交換信息，而且交換的信息僅僅是數據，那么這種耦合稱為數據耦合。如果傳遞的信息中有控制信息(盡管有時這種控制信息以數據的形式出現)，則這種耦合稱為控制耦合。數據耦合是低耦合。系統(tǒng)中至少必須存在這種耦合，因為只有當某些模塊的輸出數據作為另一些模塊的輸入數據時，系統(tǒng)才能完成有價值的功能。一般說來，一個系統(tǒng)內可以只包含數據耦合?？刂岂詈鲜侵械瘸潭鹊鸟詈?，它增加了系統(tǒng)的復雜程度?？刂岂詈贤嵌嘤嗟模诎涯K適當分解之后通?？梢杂脭祿詈洗嫠?。 如果被調用的模塊需要使用作為參數傳遞進來的數據結構中的所有元素，那么，把整個數據結構作為參數傳遞就是完全

24、正確的。但是，當把整個數據結構作為參數傳遞而被調用的模塊只需要使用其中一部分數據元素時，就出現了特征耦合。在這種情況下，被調用的模塊可以使用的數據多于它確實需要的數據，這將導致對數據的訪問失去控制，從而給計算機犯罪提供了機會。當兩個或多個模塊通過一個公共數據環(huán)境相互作用時，它們之間的耦合稱為公共環(huán)境耦合。公共環(huán)境可以是全程變量、共享的通信區(qū)、內存的公共覆蓋區(qū)、任何存儲介質上的文件、物理設備等等。 公共環(huán)境耦合的復雜程度隨耦合的模塊個數而變化，當耦合的模塊個數增加時復雜程度顯著增加。如果只有兩個模塊有公共環(huán)境，那么這種耦合有下面兩種可能：(1) 一個模塊往公共環(huán)境送數據，另一個模塊從公共環(huán)境取數

25、據。這是數據耦合的一種形式，是比較松散的耦合。(2) 兩個模塊都既往公共環(huán)境送數據又從里面取數據，這種耦合比較緊密，介于數據耦合和控制耦合之間。如果兩個模塊共享的數據很多，都通過參數傳遞可能很不方便，這時可以利用公共環(huán)境耦合。 最高程度的耦合是內容耦合。如果出現下列情況之一，兩個模塊間就發(fā)生了內容耦合：一個模塊訪問另一個模塊的內部數據；一個模塊不通過正常入口而轉到另一個模塊的內部；兩個模塊有一部分程序代碼重疊(只可能出現在匯編程序中)；一個模塊有多個入口(這意味著一個模塊有幾種功能)。應該堅決避免使用內容耦合。事實上許多高級程序設計語言已經設計成不允許在程序中出現任何形式的內容耦合。 總之，耦

26、合是影響軟件復雜程度的一個重要因素。應該采取下述設計原則：盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，完全不用內容耦合。2. 內聚內聚標志一個模塊內各個元素彼此結合的緊密程度，它是信息隱藏和局部化概念的自然擴展。簡單地說，理想內聚的模塊只做一件事情。設計時應該力求做到高內聚，通常中等程度的內聚也是可以采用的，而且效果和高內聚相差不多；但是，低內聚很壞，不要使用。 內聚和耦合是密切相關的，模塊內的高內聚往往意味著模塊間的松耦合。內聚和耦合都是進行模塊化設計的有力工具，但是實踐表明內聚更重要，應該把更多注意力集中到提高模塊的內聚程度上。低內聚有如下幾類：如果一個模塊完成一組任

27、務，這些任務彼此間即使有關系，關系也是很松散的，就叫做偶然內聚。有時在寫完一個程序之后，發(fā)現一組語句在兩處或多處出現，于是把這些語句作為一個模塊以節(jié)省內存，這樣就出現了偶然內聚的模塊。如果一個模塊完成的任務在邏輯上屬于相同或相似的一類，則稱為邏輯內聚。如果一個模塊包含的任務必須在同一段時間內執(zhí)行，就叫時間內聚。 在偶然內聚的模塊中，各種元素之間沒有實質性聯(lián)系，很可能在一種應用場合需要修改這個模塊，在另一種應用場合又不允許這種修改，從而陷入困境。事實上，偶然內聚的模塊出現修改錯誤的概率比其他類型的模塊高得多。在邏輯內聚的模塊中，不同功能混在一起，合用部分程序代碼，即使局部功能的修改有時也會影響全

28、局。因此，這類模塊的修改也比較困難。時間關系在一定程度上反映了程序的某些實質，所以時間內聚比邏輯內聚好一些。 中內聚主要有兩類：如果一個模塊內的處理元素是相關的，而且必須以特定次序執(zhí)行，則稱為過程內聚。使用程序流程圖作為工具設計軟件時，常常通過研究流程圖確定模塊的劃分，這樣得到的往往是過程內聚的模塊。如果模塊中所有元素都使用同一個輸入數據和(或)產生同一個輸出數據，則稱為通信內聚。 高內聚也有兩類：如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執(zhí)行(通常一個處理元素的輸出數據作為下一個處理元素的輸入數據)，則稱為順序內聚。根據數據流圖劃分模塊時，通常得到順序內聚的模塊，這種

29、模塊彼此間的連接往往比較簡單。如果模塊內所有處理元素屬于一個整體，完成一個單一的功能，則稱為功能內聚。功能內聚是最高程度的內聚。耦合和內聚的概念是Constantine,Yourdon,Myers和Stevens等人提出來的。按照他們的觀點，如果給上述七種內聚的優(yōu)劣評分，將得到如下結果： 功能內聚10分時間內聚3分順序內聚9分邏輯內聚1分通信內聚7分偶然內聚0分過程內聚5分事實上，沒有必要精確確定內聚的級別。重要的是設計時力爭做到高內聚，并且能夠辨認出低內聚的模塊，有能力通過修改設計提高模塊的內聚程度降低模塊間的耦合程度，從而獲得較高的模塊獨立性。 人們在開發(fā)計算機軟件的長期實踐中積累了豐富的

30、經驗，總結這些經驗得出了一些啟發(fā)式規(guī)則。這些啟發(fā)式規(guī)則雖然不像上一節(jié)講述的基本原理和概念那樣普遍適用，但是在許多場合仍然能給軟件工程師以有益的啟示，往往能幫助他們找到改進軟件設計提高軟件質量的途徑。下面介紹幾條啟發(fā)式規(guī)則。5.3 啟發(fā)規(guī)則 1. 改進軟件結構提高模塊獨立性設計出軟件的初步結構以后，應該審查分析這個結構，通過模塊分解或合并，力求降低耦合提高內聚。例如，多個模塊公有的一個子功能可以獨立成一個模塊，由這些模塊調用；有時可以通過分解或合并模塊以減少控制信息的傳遞及對全程數據的引用，并且降低接口的復雜程度。 2. 模塊規(guī)模應該適中經驗表明，一個模塊的規(guī)模不應過大，最好能寫在一頁紙內(通常

31、不超過60行語句)。有人從心理學角度研究得知，當一個模塊包含的語句數超過30以后，模塊的可理解程度迅速下降。過大的模塊往往是由于分解不充分，但是進一步分解必須符合問題結構，一般說來，分解后不應該降低模塊獨立性。過小的模塊開銷大于有效操作，而且模塊數目過多將使系統(tǒng)接口復雜。因此過小的模塊有時不值得單獨存在，特別是只有一個模塊調用它時，通常可以把它合并到上級模塊中去而不必單獨存在。 3. 深度、寬度、扇出和扇入都應適當深度表示軟件結構中控制的層數，它往往能粗略地標志一個系統(tǒng)的大小和復雜程度。深度和程序長度之間應該有粗略的對應關系，當然這個對應關系是在一定范圍內變化的。如果層數過多則應該考慮是否有許

32、多管理模塊過分簡單了，能否適當合并。寬度是軟件結構內同一個層次上的模塊總數的最大值。一般說來，寬度越大系統(tǒng)越復雜。對寬度影響最大的因素是模塊的扇出。 扇出是一個模塊直接控制(調用)的模塊數目，扇出過大意味著模塊過分復雜，需要控制和協(xié)調過多的下級模塊；扇出過小(例如總是1)也不好。經驗表明，一個設計得好的典型系統(tǒng)的平均扇出通常是3或4(扇出的上限通常是59)。扇出太大一般是因為缺乏中間層次，應該適當增加中間層次的控制模塊。扇出太小時可以把下級模塊進一步分解成若干個子功能模塊，或者合并到它的上級模塊中去。當然分解模塊或合并模塊必須符合問題結構，不能違背模塊獨立原理。 一個模塊的扇入表明有多少個上級

33、模塊直接調用它，扇入越大則共享該模塊的上級模塊數目越多，這是有好處的，但是，不能違背模塊獨立原理單純追求高扇入。觀察大量軟件系統(tǒng)后發(fā)現，設計得很好的軟件結構通常頂層扇出比較高，中層扇出較少，底層扇入到公共的實用模塊中去(底層模塊有高扇入)。 4. 模塊的作用域應該在控制域之內模塊的作用域定義為受該模塊內一個判定影響的所有模塊的集合。模塊的控制域是這個模塊本身以及所有直接或間接從屬于它的模塊的集合。例如，在圖5.2中模塊A的控制域是A、B、C、D、E、F等模塊的集合。在一個設計得很好的系統(tǒng)中，所有受判定影響的模塊應該都從屬于做出判定的那個模塊，最好局限于做出判定的那個模塊本身及它的直屬下級模塊。

34、 圖5.2 模塊的作用域和控制域 5. 力爭降低模塊接口的復雜程度模塊接口復雜是軟件發(fā)生錯誤的一個主要原因。應該仔細設計模塊接口，使得信息傳遞簡單并且和模塊的功能一致。接口復雜或不一致(即看起來傳遞的數據之間沒有聯(lián)系)，是緊耦合或低內聚的征兆，應該重新分析這個模塊的獨立性。6. 設計單入口單出口的模塊這條啟發(fā)式規(guī)則警告軟件工程師不要使模塊間出現內容耦合。當從頂部進入模塊并且從底部退出來時，軟件是比較容易理解的，因此也是比較容易維護的。 7. 模塊功能應該可以預測模塊的功能應該能夠預測，但也要防止模塊功能過分局限。如果一個模塊可以當做一個黑盒子，也就是說，只要輸入的數據相同就產生同樣的輸出，這個

35、模塊的功能就是可以預測的。帶有內部“存儲器”的模塊的功能可能是不可預測的，因為它的輸出可能取決于內部存儲器(例如某個標記)的狀態(tài)。由于內部存儲器對于上級模塊而言是不可見的，所以這樣的模塊既不易理解又難于測試和維護。 如果一個模塊只完成一個單獨的子功能，則呈現高內聚；但是，如果一個模塊任意限制局部數據結構的大小，過分限制在控制流中可以做出的選擇或者外部接口的模式，那么這種模塊的功能就過分局限，使用范圍也就過分狹窄了。在使用過程中將不可避免地需要修改功能過分局限的模塊，以提高模塊的靈活性，擴大它的使用范圍；但是，在使用現場修改軟件的代價是很高的。以上列出的啟發(fā)式規(guī)則多數是經驗規(guī)律，對改進設計，提高

36、軟件質量，往往有重要的參考價值；但是，它們既不是設計的目標也不是設計時應該普遍遵循的原理。 層次圖用來描繪軟件的層次結構。在圖5.2中已經非正式地使用了層次圖。雖然層次圖的形式和第3.7節(jié)中介紹的描繪數據結構的層次方框圖相同，但是表現的內容卻完全不同。層次圖中的一個矩形框代表一個模塊，方框間的連線表示調用關系而不像層次方框圖那樣表示組成關系。圖5.3是層次圖的一個例子。5.4 描繪軟件結構的圖形工具 5.4.1 層次圖和HIPO圖 圖5.3 正文加工系統(tǒng)的層次圖 層次圖很適于在自頂向下設計軟件的過程中使用。HIPO圖是美國IBM公司發(fā)明的“層次圖加輸入/處理/輸出圖”的英文縮寫。為了能使HIP

37、O圖具有可追蹤性，在H圖(層次圖)里除了最頂層的方框之外，每個方框都加了編號。編號規(guī)則和第2.4節(jié)中介紹的數據流圖的編號規(guī)則相同，例如，圖5.3加了編號后得到圖5.4。和H圖中每個方框相對應，應該有一張IPO圖描繪這個方框代表的模塊的處理過程。HIPO圖中的每張IPO圖內都應該明顯地標出它所描繪的模塊在H圖中的編號，以便追蹤了解這個模塊在軟件結構中的位置。 圖5.4 帶編號的層次圖(H圖) Yourdon提出的結構圖是進行軟件結構設計的另一個有力工具。結構圖和層次圖類似，也是描繪軟件結構的圖形工具，圖中一個方框代表一個模塊，框內注明模塊的名字或主要功能；方框之間的箭頭(或直線)表示模塊的調用關

38、系。因為按照慣例總是圖中位于上方的方框代表的模塊調用下方的模塊，即使不用箭頭也不會產生二義性，為了簡單起見，可以只用直線而不用箭頭表示模塊間的調用關系。5.4.2 結構圖 在結構圖中通常還用帶注釋的箭頭表示模塊調用過程中來回傳遞的信息。如果希望進一步標明傳遞的信息是數據還是控制信息，則可以利用注釋箭頭尾部的形狀來區(qū)分：尾部是空心圓表示傳遞的是數據，實心圓表示傳遞的是控制信息。圖5.5是結構圖的一個例子。以上介紹的是結構圖的基本符號，也就是最經常使用的符號。此外還有一些附加的符號，可以表示模塊的選擇調用或循環(huán)調用。圖5.6表示當模塊M中某個判定為真時調用模塊A，為假時調用模塊B。圖5.7表示模塊

39、M循環(huán)調用模塊A、B和C。 圖5.5 結構圖的例子產生最佳解的一般結構 圖5.6 判定為真時調用A，為假時調用B 圖5.7 模塊M循環(huán)調用模塊A、B、C 注意，層次圖和結構圖并不嚴格表示模塊的調用次序。雖然多數人習慣于按調用次序從左到右畫模塊，但并沒有這種規(guī)定，出于其他方面的考慮(例如為了減少交叉線)，也完全可以不按這種次序畫。此外，層次圖和結構圖并不指明什么時候調用下層模塊。通常上層模塊中除了調用下層模塊的語句之外還有其他語句，究竟是先執(zhí)行調用下層模塊的語句還是先執(zhí)行其他語句，在圖中絲毫沒有指明。事實上，層次圖和結構圖只表明一個模塊調用那些模塊，至于模塊內還有沒有其他成分則完全沒有表示。 通

40、常用層次圖作為描繪軟件結構的文檔。結構圖作為文檔并不很合適，因為圖上包含的信息太多有時反而降低了清晰程度。但是，利用IPO圖或數據字典中的信息得到模塊調用時傳遞的信息，從而由層次圖導出結構圖的過程，卻可以作為檢查設計正確性和評價模塊獨立性的好方法。傳送的每個數據元素都是完成模塊功能所必須的嗎?反之，完成模塊功能必須的每個數據元素都傳送來了嗎?所有數據元素都只和單一的功能有關嗎?如果發(fā)現結構圖上模塊間的聯(lián)系不容易解釋，則應該考慮是否設計上有問題。 面向數據流的設計方法的目標是給出設計軟件結構的一個系統(tǒng)化的途徑。在軟件工程的需求分析階段，信息流是一個關鍵考慮，通常用數據流圖描繪信息在系統(tǒng)中加工和流

41、動的情況。面向數據流的設計方法定義了一些不同的“映射”，利用這些映射可以把數據流圖變換成軟件結構。因為任何軟件系統(tǒng)都可以用數據流圖表示，所以面向數據流的設計方法理論上可以設計任何軟件的結構。通常所說的結構化設計方法(簡稱SD方法)，也就是基于數據流的設計方法。5.5 面向數據流的設計方法 面向數據流的設計方法把信息流映射成軟件結構，信息流的類型決定了映射的方法。信息流有下述兩種類型。1. 變換流參看圖5.8，信息沿輸入通路進入系統(tǒng)，同時由外部形式變換成內部形式，進入系統(tǒng)的信息通過變換中心，經加工處理以后再沿輸出通路變換成外部形式離開軟件系統(tǒng)。當數據流圖具有這些特征時，這種信息流就叫作變換流。5

42、.5.1 概念 圖5.8 變換流 圖5.9 事務流 2. 事務流基本系統(tǒng)模型意味著變換流，因此，原則上所有信息流都可以歸結為這一類。但是，當數據流圖具有和圖5.9類似的形狀時，這種數據流是“以事務為中心的”，也就是說，數據沿輸入通路到達一個處理T，這個處理根據輸入數據的類型在若干個動作序列中選出一個來執(zhí)行。這類數據流應該劃為一類特殊的數據流，稱為事務流。圖5.9中的處理T稱為事務中心，它完成下述任務：(1) 接收輸入數據(輸入數據又稱為事務)；(2) 分析每個事務以確定它的類型；(3) 根據事務類型選取一條活動通路。 3. 設計過程圖5.10（見書96頁）說明了使用面向數據流方法逐步設計的過程

43、。應該注意，任何設計過程都不是機械地一成不變的，設計首先需要人的判斷力和創(chuàng)造精神，這往往會凌駕于方法的規(guī)則之上。 變換分析是一系列設計步驟的總稱，經過這些步驟把具有變換流特點的數據流圖按預先確定的模式映射成軟件結構。下面通過一個例子說明變換分析的方法。1. 例子我們已經開始進入“智能”產品時代。在這類產品中把軟件做在只讀存儲器中，成為設備的一部分，從而使設備具有某些“智能”。因此，這類產品的設計都包含軟件開發(fā)的任務。作為面向數據流的設計方法中變換分析的例子，考慮汽車數字儀表板的設計。5.5.2 變換分析 假設的儀表板將完成下述功能：(1) 通過模數轉換實現傳感器和微處理機接口；(2) 在發(fā)光二

44、極管面板上顯示數據；(3) 指示每小時英里數(mph)，行駛的里程，每加侖油行駛的英里數(mpg)等等；(4) 指示加速或減速；(5) 超速警告：如果車速超過55英里/小時，則發(fā)出超速警告鈴聲。在軟件需求分析階段應該對上述每條要求以及系統(tǒng)的其他特點進行全面的分析評價，建立起必要的文檔資料，特別是數據流圖。 2. 設計步驟第1步 復查基本系統(tǒng)模型。復查的目的是確保系統(tǒng)的輸入數據和輸出數據符合實際。第2步 復查并精化數據流圖。應該對需求分析階段得出的數據流圖認真復查，并且在必要時進行精化。不僅要確保數據流圖給出了目標系統(tǒng)的正確的邏輯模型，而且應該使數據流圖中每個處理都代表一個規(guī)模適中相對獨立的子功

45、能。假設在需求分析階段產生的數字儀表板系統(tǒng)的數據流圖如圖5.11（見書97頁）所示。 這個數據流圖對于軟件結構設計的“第一次分割”而言已經足夠詳細了，因此不需要精化就可以進行下一個設計步驟。第3步 確定數據流圖具有變換特性還是事務特性。一般地說，一個系統(tǒng)中的所有信息流都可以認為是變換流，但是，當遇到有明顯事務特性的信息流時，建議采用事務分析方法進行設計。在這一步，設計人員應該根據數據流圖中占優(yōu)勢的屬性，確定數據流的全局特性。此外還應該把具有和全局特性不同的特點的局部區(qū)域孤立出來，以后可以按照這些子數據流的特點精化根據全局特性得出的軟件結構。 從圖5.11看出，數據沿著兩條輸入通路進入系統(tǒng)，然后

46、沿著5條通路離開，沒有明顯的事務中心。因此可以認為這個信息流具有變換流的總特征。第4步 確定輸入流和輸出流的邊界，從而孤立出變換中心。輸入流和輸出流的邊界和對它們的解釋有關，也就是說，不同設計人員可能會在流內選取稍微不同的點作為邊界的位置。當然在確定邊界時應該仔細認真，但是把邊界沿著數據流通路移動一個處理框的距離，通常對最后的軟件結構只有很小的影響。對于汽車數字儀表板的例子，設計人員確定的流的邊界如圖5.12（見書98頁）所示。 第5步 完成“第一級分解”。軟件結構代表對控制的自頂向下的分配，所謂分解就是分配控制的過程。對于變換流的情況，數據流圖被映射成一個特殊的軟件結構，這個結構控制輸入、變

47、換和輸出等信息處理過程。圖5.13說明了第一級分解的方法。位于軟件結構最頂層的控制模塊Cm協(xié)調下述從屬的控制功能：輸入信息處理控制模塊Ca,協(xié)調對所有輸入數據的接收；變換中心控制模塊Ct,管理對內部形式的數據的所有操作； 輸出信息處理控制模塊Ce，協(xié)調輸出信息的產生過程。雖然圖5.13意味著一個三叉的控制結構，但是，對一個大型系統(tǒng)中的復雜數據流可以用兩個或多個模塊完成上述一個模塊的控制功能。應該在能夠完成控制功能并且保持好的耦合和內聚特性的前提下，盡量使第一級控制中的模塊數目取最小值。對于數字儀表板的例子，第一級分解得出的結構如圖5.14所示。每個控制模塊的名字表明了為它所控制的那些模塊的功能

48、。 圖5.13 第一級分解的方法 圖5.14 數字儀表板系統(tǒng)的第一級分解 第6步 完成“第二級分解”。所謂第二級分解就是把數據流圖中的每個處理映射成軟件結構中一個適當的模塊。完成第二級分解的方法是，從變換中心的邊界開始沿著輸入通路向外移動，把輸入通路中每個處理映射成軟件結構中Ca控制下的一個低層模塊；然后沿輸出通路向外移動，把輸出通路中每個處理映射成直接或間接受模塊Ce控制的一個低層模塊；最后把變換中心內的每個處理映射成受Ct控制的一個模塊。圖5.15表示進行第二級分解的普遍途徑。 圖5.15 第二級分解的方法 雖然圖5.15描繪了在數據流圖中的處理和軟件結構中的模塊之間的一對一的映射關系，但

49、是，不同的映射經常出現。應該根據實際情況以及“好”設計的標準，進行實際的第二級分解。對于數字儀表板系統(tǒng)的例子，第二級分解的結果分別用圖5.16，5.17和5.18描繪。這3張圖表示對軟件結構的初步設計結果。雖然圖中每個模塊的名字表明了它的基本功能，但是仍然應該為每個模塊寫一個簡要說明，描述： 進出該模塊的信息(接口描述)；模塊內部的信息；過程陳述，包括主要判定點及任務等；對約束和特殊特點的簡短討論。這些描述是第一代的設計規(guī)格說明，在這個設計時期進一步的精化和補充是經常發(fā)生的。第7步 使用設計度量和啟發(fā)式規(guī)則對第一次分割得到的軟件結構進一步精化。 圖5.16 未經精化的輸入結構 圖5.17 未經

50、精化的變換結構 圖5.18 未經精化的輸出結構 對第一次分割得到的軟件結構，總可以根據模塊獨立原理進行精化。為了產生合理的分解，得到盡可能高的內聚、盡可能松散的耦合，最重要的是，為了得到一個易于實現、易于測試和易于維護的軟件結構，應該對初步分割得到的模塊進行再分解或合并。具體到數字儀表板的例子，對于從前面的設計步驟得到的軟件結構，還可以做許多修改。下面是某些可能的修改：輸入結構中的模塊“轉換成rpm”和“收集sps”可以合并；模塊“確定加速/減速”可以放在模塊“計算mph”下面，以減少耦合； 模塊“加速/減速顯示”可以相應地放在模塊“顯示mph”的下面。經過上述修改后的軟件結構畫在圖5.19中

51、。上述7個設計步驟的目的是，開發(fā)出軟件的整體表示。也就是說，一旦確定了軟件結構就可以把它作為一個整體來復查，從而能夠評價和精化軟件結構。在這個時期進行修改只需要很少的附加工作，但是卻能夠對軟件的質量特別是軟件的可維護性產生深遠的影響。 圖5.19 精化后的數字儀表板系統(tǒng)的軟件結構 雖然在任何情況下都可以使用變換分析方法設計軟件結構，但是在數據流具有明顯的事務特點時，也就是有一個明顯的“發(fā)射中心”(事務中心)時，還是以采用事務分析方法為宜。事務分析的設計步驟和變換分析的設計步驟大部分相同或類似，主要差別僅在于由數據流圖到軟件結構的映射方法不同。5.5.3 事務分析 由事務流映射成的軟件結構包括一

52、個接收分支和一個發(fā)送分支。映射出接收分支結構的方法和變換分析映射出輸入結構的方法很相像，即從事務中心的邊界開始，把沿著接收流通路的處理映射成模塊。發(fā)送分支的結構包含一個調度模塊，它控制下層的所有活動模塊；然后把數據流圖中的每個活動流通路映射成與它的流特征相對應的結構。圖5.20說明了上述映射過程。對于一個大系統(tǒng)，常常把變換分析和事務分析應用到同一個數據流圖的不同部分，由此得到的子結構形成“構件”，可以利用它們構造完整的軟件結構。 圖5.20 事務分析的映射方法 一般說來，如果數據流不具有顯著的事務特點，最好使用變換分析；反之，如果具有明顯的事務中心，則應該采用事務分析技術。但是，機械地遵循變換

53、分析或事務分析的映射規(guī)則，很可能會得到一些不必要的控制模塊，如果它們確實用處不大，那么可以而且應該把它們合并。反之，如果一個控制模塊功能過分復雜，則應該分解為兩個或多個控制模塊，或者增加中間層次的控制模塊。 考慮設計優(yōu)化問題時應該記住，“一個不能工作的最佳設計的價值是值得懷疑的”。軟件設計人員應該致力于開發(fā)能夠滿足所有功能和性能要求，而且按照設計原理和啟發(fā)式設計規(guī)則衡量是值得接收的軟件。應該在設計的早期階段盡量對軟件結構進行精化。可以導出不同的軟件結構，然后對它們進行評價和比較，力求得到“最好”的結果。這種優(yōu)化的可能，是把軟件結構設計和過程設計分開的真正優(yōu)點之一。5.5.4 設計優(yōu)化 注意，結

54、構簡單通常既表示設計風格優(yōu)雅，又表明效率高。設計優(yōu)化應該力求做到在有效的模塊化的前提下使用最少量的模塊，以及在能夠滿足信息要求的前提下使用最簡單的數據結構。對于時間是決定性因素的應用場合，可能有必要在詳細設計階段，也可能在編寫程序的過程中進行優(yōu)化。軟件開發(fā)人員應該認識到，程序中相對說比較小的部分(典型地，10%20%)，通常占用全部處理時間的大部分(50%80%)。用下述方法對時間起決定性作用的軟件進行優(yōu)化是合理的： (1) 在不考慮時間因素的前提下開發(fā)并精化軟件結構；(2) 在詳細設計階段選出最耗費時間的那些模塊，仔細地設計它們的處理過程(算法)，以求提高效率；(3) 使用高級程序設計語言編

55、寫程序；(4) 在軟件中孤立出那些大量占用處理機資源的模塊；(5) 必要時重新設計或用依賴于機器的語言重寫上述大量占用資源的模塊的代碼，以求提高效率。上述優(yōu)化方法遵守了一句格言：“先使它能工作，然后再使它快起來?！?總體設計階段的基本目的是用比較抽象概括的方式確定系統(tǒng)如何完成預定的任務，也就是說，應該確定系統(tǒng)的物理配置方案，并且進而確定組成系統(tǒng)的每個程序的結構。因此，總體設計階段主要由兩個小階段組成。首先需要進行系統(tǒng)設計，從數據流圖出發(fā)設想完成系統(tǒng)功能的若干種合理的物理方案，分析員應該仔細分析比較這些方案，并且和用戶共同選定一個最佳方案。然后進行軟件結構設計，確定軟件由哪些模塊組成以及這些模塊

56、之間的動態(tài)調用關系。層次圖和結構圖是描繪軟件結構的常用工具。5.6 小結 在進行軟件結構設計時應該遵循的最主要的原理是模塊獨立原理，也就是說，軟件應該由一組完成相對獨立的子功能的模塊組成，這些模塊彼此之間的接口關系應該盡量簡單。抽象和求精是一對互補的概念，也是人類解決復雜問題時最常用、最有效的方法。在進行軟件結構設計時一種有效的方法就是，由抽象到具體地構造出軟件的層次結構。 軟件工程師在開發(fā)軟件的長期實踐中積累了豐富的經驗，總結這些經驗得出一些很有參考價值的啟發(fā)式規(guī)則，它們往往能對如何改進軟件設計給出寶貴的提示。在軟件開發(fā)過程中既要充分重視和利用這些啟發(fā)式規(guī)則，又要從實際情況出發(fā)避免生搬硬套。

57、自頂向下逐步求精是進行軟件結構設計的常用途徑；但是，如果已經有了詳細的數據流圖，也可以使用面向數據流的設計方法，用形式化的方法由數據流圖映射出軟件結構。應該記住，這樣映射出來的只是軟件的初步結構，還必須根據設計原理并且參考啟發(fā)式規(guī)則，認真分析和改進軟件的初步結構，以得到質量更高的模塊和更合理的軟件結構。 在進行詳細的過程設計和編寫程序之前，首先進行結構設計，其好處正在于可以在軟件開發(fā)的早期站在全局高度對軟件結構進行優(yōu)化。在這個時期進行優(yōu)化付出的代價不高，卻可以使軟件質量得到重大改進。 5-1 為每種類型的模塊耦合舉一個具體例子。5-2 為每種類型的模塊內聚舉一個具體例子。5-3 用面向數據流的

58、方法設計下列系統(tǒng)的軟件結構：(1) 儲蓄系統(tǒng)(參見習題2第2題)；(2) 機票預訂系統(tǒng)(參見習題2第3題)；(3) 患者監(jiān)護系統(tǒng)(參見習題2第4題)。習題 5-4 美國某大學共有200名教師，校方與教師工會剛剛簽訂一項協(xié)議。按照協(xié)議，所有年工資超過26 000(含26 000)的教師工資將保持不變，年工資少于26 000的教師將增加工資，所增加的工資數按下述方法計算：給每個由此教師所贍養(yǎng)的人(包括教師本人)每年補助100，此外，教師有一年工齡每年再多補助50，但是，增加后的年工資總額不能多于26 000。教師的工資檔案儲存在行政辦公室的磁帶上，檔案中有目前的年工資、贍養(yǎng)的人數、雇用日期等信息。

59、需要寫一個程序計算并印出每名教師的原有工資和調整后的新工資。要求： (1) 畫出此系統(tǒng)的數據流圖；(2) 寫出需求說明；(3) 設計上述的工資調整程序(要求用HIPO圖描繪設計結果)，設計時請分別采用下述兩種算法，并比較這兩種算法的優(yōu)缺點：(a) 搜索工資檔案數據，找出年工資少于26 000的人，計算新工資，校核是否超過26 000，儲存新工資，印出新舊工資對照表；(b) 把工資檔案數據按工資從最低到最高的次序排序，當工資數額超過26 000時即停止排序，計算新工資，校核是否超過限額，儲存新工資，印出結果。 (4) 你所畫出的數據流圖適用于哪種算法?5-5 下面將給出兩個人玩的撲克牌游戲的一種

60、玩法，請你設計一個模擬程序，它的基本功能是： (1)發(fā)兩手牌(利用隨機數產生器)； (2)確定贏者和贏牌的類型； (3)模擬N次游戲，計算每種類型牌贏或平局的概率。要求用HIPO圖描繪設計結果并且畫出高層控制流程圖。撲克牌游戲規(guī)則如下：(1) 有兩個人玩，分別稱為A和B；(2) 一副撲克牌有52張牌，4 種花色(方塊、梅花、紅桃和黑桃)，每種花色的牌的點數按升序排列有2，3，4，10，J，Q，K，A等13種； (3) 給每個人發(fā)3張牌，牌面向上(即，亮牌)，贏者立即可以確定；(4) 最高等級的一手牌稱為同花，即3張牌均為同一種花色，最大的同花牌是同一種花色的Q、K、A；(5) 第二等級的牌稱為順子，即點數連續(xù)的3張牌，最大的順子是花色不同的Q、K、A；(6) 第三等級的牌是同點，即點數相同的3張牌，最大的同點是A、A、A；(7) 第四等級的牌是對子，即3張牌中有兩張點數相同，最大的對子是A、A、K； (8) 第五等級的牌是雜牌，即除去上列四等之外的任何一手牌，最大的雜牌是不同花色的A、K、J；(9) 若兩人的牌類型不同，則等級高者勝；若等級相同，則點數高者勝；若點數也相同，則為平局。