教學內容
第四章總體設計
4.1設計過程
總體設計過程通常由兩個主要階段組成:系統設計階段,確定系統的具體實現方案;結構設計階段,確定軟體結構。典型的總體設計過程包括下述9個步驟。
1．設想供選擇的方案2．選取合理的方案3．推薦最佳方案4．功能分解
5．設計軟體結構6．設計資料庫7．制定測試計畫8．書寫文件9．審查和複審4.2設計原理
本節講述軟體設計過程中應遵循的基本原理和相關概念。4.2.1模組化
軟體總體結構體現了模組化思想，即把軟體劃分為可獨立命名和編制的部件，每個部件稱為乙個模組，當把所有模組組裝到一起時，便可獲得滿足問題需要的乙個解。
4.2.2抽象與逐步求精
抽象是控制複雜性的基本策略。「抽象」 要求人們將注意力集中在某一層次上考慮問題，而忽略那些低層次的細節。
1.抽象
在系統定義階段，軟體系統被描述為基於計算機的大系統的乙個組成部分；在軟體規劃和需求分析階段，軟體用問題域約定的習慣用語表達；從概要設計過渡到詳細設計時，抽象級再一次降低；編碼完成後達到了抽象的最低階。2.逐步求精
關於「逐步求精」，曾經做過如下說明：
「我們對付複雜問題的重要辦法是抽象，因此，對乙個複雜的問題不應該立即用計算機指令、數字和邏輯符號來表示，而應該用較自然的抽象語言來表示，從而得出抽象程式。抽象程式對抽象的資料進行某些特定的運算並用某些合適的記號（可能是自然語言）來表示。對抽象程式做進一步分解，進入下乙個抽象層次，重複這一精化過程直到程式能被計算機接受為止。
這時的程式可能是用某種高階語言或機器指令書寫的。」4.2.
3模組化與資訊隱藏
1．資訊隱蔽
資訊隱蔽原理告訴我們，模組應該設計得使其所含資訊（過程和資料）對於那些不需要這些資訊的模組不可訪問；每個模組只完成乙個相對獨立的特定功能；模組之間僅僅交換那些為完成系統功能必須交換的資訊，即模組應該獨立。顯然，模組獨立的概念是模組化、抽象、資訊隱蔽和區域性化等諸多概念的直接結果。
2．內聚度（cohesion）1備註
內聚度是前述資訊隱蔽和區域性化概念的自然擴充套件，它標誌乙個模組內部各成分彼此結合的緊密程度。
內聚度按其高低程度可分為七級，內聚度越高越好。
1）偶然性內聚——低階內聚2）邏輯性內聚——低階內聚3）時間性內聚——低階內聚4）過程性內聚——中級內聚5）通訊性內聚度——中級內聚6）順序性內聚——高階內聚7）功能性內聚——高階內聚
3．耦合度
耦合的強弱取決於模組間介面的複雜性、進入或呼叫模組的位置以及通過介面傳送資料的多少等。模組間的耦合程度直接影響系統的可理解性、可測試性、可靠性和可維護性。
耦合度也可以分為七級
1）非直接耦合——最鬆散的耦合2）資料耦合3）特徵耦合4）控制耦合5）外部耦合
6）公共耦合7）內容耦合
一般來說，設計軟體時應盡量使用資料耦合，減少控制耦合，限制外部環境耦合和公共資料耦合，杜絕內容耦合。4.3啟發規則
人們在開發計算機軟體的長期時間中積累了豐富的經驗,總結這些經驗得出了一些啟發式規則.雖然不具有普遍性,但在很多場合仍然能給軟體工程師以有益啟示。這一節課我們簡單介紹一下：
1．改進軟體結構提高模組獨立性2．模組規模應適中
3．深度、寬度、扇出和扇入都應適當4．模組的作用域應該在控制域之內5．力爭降低模組藉口的複雜程度6．設計單入口單出口的模組7．模組功能應該可以**4.4描繪軟體結構的圖形工具4.4.
1層次圖和hipo圖
層次圖用來描繪軟體的層次結構.層次圖很適於自頂向下設計軟體的過程使用。hipo圖是美國ibm公司發明的「層次圖加輸入/處理/輸出圖」的英文縮寫。
為了能使hipo圖具有可追蹤性，在h圖里除了最頂層的方框之外，每個方框都加了編號。具體內容見第三章.4.
4.2結構圖
yourdon提出的結構圖是進行軟體結構設計的另一種有力工具.結構圖和層次圖類似,也是描繪軟體結構的圖形工具,圖中乙個方框代表乙個模組,框內註明
2模組的名稱或主要功能;方框之間的箭頭(或直線)表示模組的呼叫關係.因為按照慣例總是圖中位於上方的方框代表呼叫下方的模組,即使不用箭頭也不會產生二義性,為了簡單起見,可以只用直線而不用箭頭表示模組間的呼叫關係。4.
5面向資料流的設計方法
面向資料流的設計方法，即通常所說的結構設計法（structure design，簡稱sd方法），由yourdon和constantine等人於2023年提出的，與結構化分析（sa）相銜接，根據對資料流的分析設計軟體結構。
4.5.1 sd方法的設計過程和有關概念
sd方法能方便地將資料流圖轉換為軟體結構，其過程分為五步：1．確定資訊流的型別；
2．劃定流界；
3．將資料流圖對映為程式結構；
4．提取層次控制結構；
5．通過設計複審和使用啟發式策略進一步精化所得到的結構。1）變換流
變換流—在基本系統模型（即頂級資料流圖）中資訊通常以「外部世界」所具有的形式進入系統，經過處理後又以這種形式離開系統。
變換流的特點是：經過變換b的資料流一部分先經過變換c到達變換e，然後另一部分經過變換d到達e；即c和d是順序結構。
2）事務流
事務流——單個資料項稱為事務（transaction）沿傳入路徑（也稱接受通道）進入系統，由外部形式變換為內部形式後到達事務中心，事務中心根據資料項計值結果從若干動作路徑中選定一條繼續執行。4.5.
2變換分析
步驟一、複審基本系統模型
基本系統模型指頂級dfd和所有由外部提供的資訊。這一設計步驟是對系統規格說明書和軟體需求規格說明書進行評估。這兩個文件描述軟體介面上資訊的流程和結構。
步驟二、複審和精化軟體資料流圖
這一步主要是對軟體需求規格說明書中的分析模型進行精化，直至獲得足夠詳細的dfd。
例如，由「感測器監測子系統」的第一級（圖4.4的區域性）和第二級（圖4.5）dfd進一步推導出第**資料流圖（圖4.
6，此時，每個變換對應乙個獨立的功能，可以用乙個具有較高內聚度的模組實現，至此已有足夠的資訊可用於設計「感測器監測子系統」的程式結構，精化過程亦可結束。
步驟三、確定dfd的特性，判定它為變換流還是事務流。以圖4.6所示dfd為例，資料沿乙個傳入路徑進來，沿三個傳出路徑離開，沒有明顯的事務中心，因此，該資訊流應屬變換流。
步驟四、劃定輸入流和輸出流的邊界，孤立變換中心。
步驟五、執行「一級分解」（first level factoring）
一級分解的目標是匯出具有三個層次的程式結構，頂層為主控模組；底層模組執行輸入、計算和輸出功能；中層模組控制、協調底層的工作。
程式結構可用yourdon結構圖表示。結構圖中，方框代表模組，框內名稱表
3示模組的功能；方框之間的有向邊（無二義時也可用無向邊）表示模組間的呼叫關係。呼叫模組上無標誌表示順序呼叫：從左至右；菱形表示選擇呼叫；弧形箭頭表示迴圈呼叫。
但本書後面除了順序呼叫外，並沒有遵循這些規定。
步驟六、執行「二級分解」。
二級分解的任務是把資料流圖中每個處理框對映為結構圖中的乙個模組。其過程是從變換中心的邊界開始沿輸入、輸出通道向外移動；從變換中心的輸入(出)邊界向外移動，把遇到的每個處理框對映為結構圖中相應控制模組下的乙個模組。
dfd的處理框與程式結構模組一一對應，但按照軟體設計原則進行設計時，可能需要把幾個處理框聚合為乙個模組，或者把乙個處理框裂變為幾個模組。總之，應根據「良好」設計的標準，進行二級分解。
二級分解後得到的僅僅是程式結構的「雛形」（firstcut），後續的複審和精化會反覆修改。
程式結構的模組名已隱含了模組功能，但仍有必要為每個模組寫乙個簡要的處理說明，它應當包括：
1．進出模組的資訊（介面描述）；2．模組的區域性資訊；
3．處理過程陳述，包括任務和主要的判斷點的位置、條件；
4．對有關限制和一些專門特性的簡要說明（例如，檔案i/o，獨立於硬體的特性，特殊的實時要求等）。
這些描述構成第一版設計規格說明書。
步驟七、採用啟發式設計策略，精化所得程式結構雛形，改良軟體質量對於程式結構的雛形，以「模組獨立」為指導思想，對模組進行整合或分解，旨在追求高內聚、低耦合，以及易實現、易測試、易維護的軟體結構。上述七個設計步驟的目標是給出軟體的乙個整體描述。一旦有了這樣乙個描述，設計人員即可從整體角度評價和精化軟體的總體結構，此時修改所需耗費不多，卻能大大提高軟體質量。
4.5.3事務分析
當資料流具有明顯的事務特徵時，即能找到乙個事務（亦稱觸發資料項）和乙個事務中心，採用事務分析法更為適宜。
下面以「家庭保安系統」中「使用者互動子系統」為例，說明事務分析法。該子系統的第一級資料流圖精化後得到如圖4.10所示第二級資料流圖。
圖中「使用者命令資料」流入系統後，沿三條動作路徑之一離開系統，若將資料項「命令型別」看作事務，該子系統的資訊流具有明顯的事務特徵。
事務分析法可概括為七個步驟：步驟
一、複審基本系統模型；
步驟二、複審並精化軟體資料流圖；
步驟三、確定資料流圖的特徵；
步驟四、指出事務中心，確定接收部分和傳送部分的流界；步驟
五、對映出系統上層模組結構；
步驟六、分解並精化事務結構以及每條動作路徑所對應的結構。這些子結構是根據流經每一動作路徑的資料流特徵，採用本節或上節所述設計步驟逐一匯出的。
步驟七、使用啟發式設計策略，精化所得程式結構雛形，改良軟體質量。這一步
4驟與變換分析法相同。4.5.4設計優化
我們努力追求的設計應該是既滿足功能和效能的要求，又符合一般軟體設計原理和上述種種啟發式設計原則。
1.對軟體結構的修改越早越好。必要時，可以並行地開發若干個軟體結構，通過評比，求得「最佳」結果。
2.簡潔的程式結構容易測試、容易維護，應該使用盡可能少的模組；只要滿足資訊要求，應該使用盡可能簡單的資料結構。
3.結構優化是乙個精益求精的過程。優化過程可以在設計的早期，甚至要延續到詳細設計乃至編碼階段。
4.對時間有特殊要求的軟體，應根據普遍存在的「百分之二十規則」（即20%的**占用80%的處理時間，80%的錯誤出自20%的**）採用下述對策：
(1)在不考慮時、空耗費的情況下，設計並精化軟體結構；
(2)借用case工具模擬分析執行時的效能，定位出低效的部分，加以改進；(3)詳細設計時對最耗時的模組，認真地設計它們的處理過程（演算法），以便減少時間的開銷；
(4)盡量用高階語言程式設計以利於軟體的優化；
(5)對大量占用計算機系統資源的模組必要時用低階語言重新編碼，以提高效率。
設計優化的格言—「先讓它幹起來，再讓它快起來」。5
軟體工程導論1 3章總結
開發軟體的基本過程 否修改是否修改是否修改是修改是生命週期方法 生命週期法採用介於形式語言和自然語言之間的描述方式，通過一套分層的資料流程圖，附以資料字典 明等工具來描述系統。生命週期法的基本思想 為保證系統開發的順利進行，生命週期法強調遵循以下幾個基本原則 一 面向使用者的觀點 資訊系統的目的是為...
ISO軟體工程 4 需求說明書
需求說明書 1 引言 1.1編寫的目的 說明編寫這份需求說明書的目的,指出預期的讀者.1.2背景 a.待開發的系統的名稱 b.本專案的任務提出者 開發者 使用者 c.該系統同其他系統或其他機構的基本的相互來往關係。1.3定義 列出本檔案中用到的專門術語的定義和外文首字母組詞的原片語。1.4參考資料 ...
軟體工程範本
測試計畫初稿 這裡所說的測試，主要是指整個程式系統的組裝測試和確認測試。本檔案的編制是為了提供乙個對該軟體的測試計畫，包括對每項測試活動的內容 進度安排 設計考慮 測試資料的整理方法及評價準則。4.實現階段 模組開發卷宗 開始編寫 模組開發卷宗是在模組開發過程中逐步編寫出來的，每完成乙個模組或一組密...