1、軟件生存周期可行性研究需求分析概要設計詳細設計實 現集成測試確認測試使用與維護退役軟件定義軟件開發軟件使用與維護軟件生命周期1軟件設計是后續開發步驟及軟件維護工作的基礎。如果沒有設計，只能建立一個不穩定的系統結構2第五章 軟件設計主要內容： 軟件設計的目標和任務 軟件設計基礎 模塊的獨立性 結構化設計方法 數據設計及文件設計 過程設計3討論要點(1)如何將分析模型轉換為軟件 設計？(2)作為軟件工程師在軟件設計 方面應使用哪些基本原則和 概念？4引言： 軟件設計的目標和目的 軟件需求：解決“做什么” 軟件設計：解決“怎么做” 1. 軟件設計的任務 問題結構(軟件需求) 軟件結構 從軟件需求規格

2、說明書出發，形成軟件的具體設計方案。映射5將分析模型轉換為軟件設計數據字典數據流圖E-R圖狀態變遷圖加工規約控制規約數據對描 述象數 據 設 計體系結構設計接口設計過程設計分析模型設計模型2.軟件的總體結構主要回答的問題軟件的組成部分軟件的層次關系模塊的內部處理邏輯模塊之間的界面73. 軟件設計的問題 工具 如何描述軟件的總體結構方法 用什么方法有問題結構導出 軟件結構評估準則 什么樣的軟件結構是 “最優的”84. 軟件設計方法結構化設計方法(SD)面向數據結構的設計方法(JSD方法)面向對象的設計方法(OOD)95. 軟件設計分為兩個階段：(1)概要設計(總體設計)確定軟件的結構以及各組成成

3、分(子系統或模塊)之間的相互關系。(2)詳細設計 確定模塊內部的算法和數據結構，產生描述各模塊程序過程的詳細文檔。10軟件設計任務從工程管理的角度來看，軟件設計分兩步完成。 概要設計，將軟件需求轉化為數據結構和軟件的系統結構。 詳細設計，即過程設計。通過對結構表示進行細化，得到軟件詳細的數據結構和算法。11軟 件 工 程-第4章 概要設計125.1 設計過程開始考慮“How”，但仍屬高層設計（確定黑盒關系）1、設想供選擇的方案2、選擇合理的方案3、確定最佳方案： 從DFD出發進行任務分解，不同的劃分方法即對應不同的方案。每個合理的方案應配備下列4份資料：系統流程圖組成系統的物理元素清單成本/效

4、益分析進度計劃選擇最佳方案并制定詳細的實現計劃4、功能分解131. 概要設計的過程5、結構設計 模塊化思想： 將DFD細化，至每個子功能都明白易懂；每個模塊完成一個子功能；每層模塊合成一個高一級的功能。 6、數據庫設計8、文檔、審查7、測試計劃14總體設計階段的文檔（1）總體設計說明書（包括系統實現方案和軟件模塊結構）；（2）測試計劃（包括測試策略、測試方案、預測的測試結果、測試進度計劃等）；（3）用戶手冊（根據總體設計階段的結果，編寫的初步的用戶操作手冊）；（4）詳細的實現計劃；（5）數據庫設計結果。155.2 軟件設計原理1、模塊化原理：經驗1：E(P1+P2)E(P1)+E(P2)經驗2

5、：成本成本 / 模塊最小成本區接口成本軟件總成本模塊數目16模塊化概念模塊：又稱構件，是能夠單獨命名并獨立地完成一定功能的程序語句的集合。例如高級語言中的過程、函數、子程序等都可作為模塊模塊化是軟件的一個重要屬性。模塊化的特性提供了人們處理復雜的問題的一種方法，同時也使得軟件能夠被有效地管理。17 模塊化 (Modularity)模塊化是好的軟件設計的一個基本準則 高層模塊 從整體上把握 問題,隱蔽細節 復雜問題 較小問題 分解 可減小解題所需的總的工作分解182. 軟件結構度量術語深度寬度扇出扇入(模塊的 層數)(同一層最大模塊數)(一個模塊 直接調用 的模塊數)(調用一個給定模 塊的模塊個

6、數)19模塊化和軟件成本成本或工作量模塊數量軟件總成本集成成本成本/模塊M最小成本區域202. 軟件設計原則2、抽象： 忽略細節，分層理解問題，自頂向下層層加細。我們在考慮問題時，集中考慮和當前問題有關的方面，而忽略和當前問題無關的方面，這就是抽象。或者說抽象就是抽出事物的本質特性而暫時不考慮它們的細節。 軟件工程過程的每一步，都是對軟件解法的抽象層次的一次細化。在可行性研究階段，軟件被看作是一個完整的系統部分；在需求分析期間，我們使用在問題環境中熟悉的術語來描述軟件的解法；當我們由總體設計階段轉入詳細設計階段時，抽象的程度進一步減少；最后，當源程序寫出來時，也就達到了抽象的最低層。例：開發一

7、個CAD軟件，實現一個二維繪圖系統的全部功能，供低級計算機輔助設計使用。21 3、信息隱蔽(Information hiding)與局部化 每一個模塊的實現細節對于其他模塊來說是隱蔽的，模塊中所包括的信息不允許其他不需要這些信息的模塊調用。 信息隱蔽對于軟件的測試與維護都有很大的好處。因為對于軟件的其它部分來說，絕大多數數據和過程都是隱蔽的，這樣，在修改期間由于疏忽而引入的錯誤所造成的影響就可以局限在一個或幾個模塊內部，不至波及到軟件的其他部分。 局部化就是將一些關系密切的軟件元素物理地放得彼此靠近。2. 軟件設計原則224、模塊獨立性(Module independence) * 好設計的關

8、鍵：每個模塊完成一個相對獨立的子功能，并且與其它模塊間的接口簡單。2. 軟件設計原則獨立性的度量：耦合(Coupling)&內聚(Cohesion) 模塊獨立性是模塊化、抽象和信息隱蔽概念的直接結果。 23 耦合(Coupling)Great deal of dependenceIndependent Highly coupledLoosely coupledUncoupled 2. 軟件設計原則耦合表示一個軟件結構內各個模塊之間的互連程度，應盡量選用松散耦合的系統24例1：A訪問C的內部數據或不通過正常入口而轉入C的內部。ABCDA:goto C1C:C1: 獨立性由弱到強（耦合程度由強到弱

9、）排列為： 內容耦合(Content Coupling): 一個模塊直接影響另一個2. 軟件設計原則25例2：部分代碼重疊（常出現在匯編程序中）B A例3：一個模塊有多個入口（功能）A:entry 1:entry 2: The least desirable2. 軟件設計原則26 公共耦合 (Common coupling)：幾個模塊共享一個數據區域Global : V1 V2A:A1=V1+V2B:V1=B1Global : V1 V2A:V1+B:V2=B1+V1問題： 公共部分的改動將影響所有調用它的模塊； 公共部分的數據存取無法控制； 復雜程度隨耦合模塊的個數增加而增加。2. 軟件設計

10、原則27控制耦合(Control coupling)：一個模塊通過傳遞控制信息來控制另一個模塊ABFlagF2F1FnFlag接口單一，但仍然影響被控模塊的內部邏輯。控制耦合:當把整個數據結構作為參數傳遞而被調用的模塊只需要使用其中一部分數據元素時，就出現了特征耦合.2. 軟件設計原則28數據耦合(Data coupling): 只有數據在模塊之間進行交換原則：盡量使用數據耦合，少用控制耦合，限制公共耦合的范圍，完全不用內容耦合。29 低內聚：偶然內聚（Coincidental cohesion） 模塊中任務沒有多大關系A:Read inputsfrom diskfrom tapefrom 邏

11、輯內聚（Logical cohesion）：相似功能放在一個模塊例如： 內聚 (Cohesion): 一個模塊內各元素結合的緊密程度.Goal: as cohesive as possible.2. 軟件設計原則30 時間內聚（Temporal cohesion）：模塊內的功能在同一時間段內完成例如：系統的初始化問題：不同功能混在一個模塊中，有時共用部分編碼，使局部功能的修改牽動全局。 中內聚： 過程內聚（Procedural cohesion）：模塊內的處理是相關的，而且必須以特定順序執行例如：enter datacheck datamanipulate data2. 軟件設計原則31 通信

12、內聚（Communicational cohesion）：模塊中所有元素都用同一個輸入數據或產生同一個輸出數據例如：從同一磁帶上讀取不相干的數據 可能破壞獨立性。 高內聚： 順序內聚（Sequential cohesion）：模塊的多個功能使用相同的數據結構和入口 功能內聚（Functional cohesion）：所有元素合力完成一個單一功能，缺一不可2. 軟件設計原則32 耦合、內聚與模塊獨立性的關系：2. 軟件設計原則335. 3 結構設計原則(啟發原則)2. 軟件設計原則34結構設計原則2. 模塊規模適中： 過大不易理解；太小則接口開銷過大。注意分解后不應降低模塊的獨立性。提高模塊獨立

13、性 爭取低耦合、高內聚（增加內聚 減少耦合）2. 軟件設計原則35 深度 = 分層的層數。過大表示分工過細。 寬度 = 同一層上模塊數的最大值。過大表示系統復雜度大。2. 軟件設計原則3. 選擇適當的深度、寬度、扇出和扇入 36 扇出 = 一個模塊直接調用控制的模塊數。 3 fan-out 9AA的扇出AA的扇入 扇入 = 直接調用該模塊的模塊數在不破壞獨立性的前提下，fan-in 大的比較好。2. 軟件設計原則374、作用域在控制域內 控制域MACBM的控制域為 M，A，B，C 作用域：M中的一個判定所影響的模塊。例如：A: if then goto B1 B: B1: 作用域在控制域內A:

14、 if then goto M1 M: M1: goto C1 作用域超出了控制域上例中A的作用超出了控制域。改進方法之一，可以把A中的 if 移到M中；方法之二，可以把C移到A下面。2. 軟件設計原則385、降低接口的復雜程度：接口復雜可能表明模塊的獨立性差。6、單出單入，避免內容耦合。7、模塊功能可預測 相同輸入必產生相同輸出。反例：模塊中使用全局變量或靜態變量，則可能導致不可預測。2. 軟件設計原則39層次圖用來描繪軟件的層次結構。在圖5.2中已經非正式地使用了層次圖。雖然層次圖的形式和第3.7節中介紹的描繪數據結構的層次方框圖相同，但是表現的內容卻完全不同。層次圖中的一個矩形框代表一個

15、模塊，方框間的連線表示調用關系而不像層次方框圖那樣表示組成關系。圖5.3是層次圖的一個例子。5.4 描繪軟件結構的圖形工具 5.4.1 層次圖和HIPO圖40圖5.3 正文加工系統的層次圖 41層次圖很適于在自頂向下設計軟件的過程中使用。HIPO圖是美國IBM公司發明的“層次圖加輸入/處理/輸出圖”的英文縮寫。為了能使HIPO圖具有可追蹤性，在H圖(層次圖)里除了最頂層的方框之外，每個方框都加了編號。和H圖中每個方框相對應，應該有一張IPO圖描繪這個方框代表的模塊的處理過程。HIPO圖中的每張IPO圖內都應該明顯地標出它所描繪的模塊在H圖中的編號，以便追蹤了解這個模塊在軟件結構中的位置。42圖

16、5.4 帶編號的層次圖(H圖)43Yourdon提出的結構圖是進行軟件結構設計的另一個有力工具。結構圖和層次圖類似，也是描繪軟件結構的圖形工具，圖中一個方框代表一個模塊，框內注明模塊的名字或主要功能；方框之間的箭頭(或直線)表示模塊的調用關系。因為按照慣例總是圖中位于上方的方框代表的模塊調用下方的模塊，即使不用箭頭也不會產生二義性，為了簡單起見，可以只用直線而不用箭頭表示模塊間的調用關系。5.4.2 結構圖44在結構圖中通常還用帶注釋的箭頭表示模塊調用過程中來回傳遞的信息。如果希望進一步標明傳遞的信息是數據還是控制信息，則可以利用注釋箭頭尾部的形狀來區分：尾部是空心圓表示傳遞的是數據，實心圓表

17、示傳遞的是控制信息。圖5.5是結構圖的一個例子。以上介紹的是結構圖的基本符號，也就是最經常使用的符號。此外還有一些附加的符號，可以表示模塊的選擇調用或循環調用。圖5.6表示當模塊M中某個判定為真時調用模塊A，為假時調用模塊B。圖5.7表示模塊M循環調用模塊A、B和C。45圖5.5 結構圖的例子產生最佳解的一般結構46圖5.6 判定為真時調用A，為假時調用B47圖5.7 模塊M循環調用模塊A、B、C48注意，層次圖和結構圖并不嚴格表示模塊的調用次序。雖然多數人習慣于按調用次序從左到右畫模塊，但并沒有這種規定，出于其他方面的考慮(例如為了減少交叉線)，也完全可以不按這種次序畫。此外，層次圖和結構圖

18、并不指明什么時候調用下層模塊。通常上層模塊中除了調用下層模塊的語句之外還有其他語句，究竟是先執行調用下層模塊的語句還是先執行其他語句，在圖中絲毫沒有指明。事實上，層次圖和結構圖只表明一個模塊調用那些模塊，至于模塊內還有沒有其他成分則完全沒有表示。49通常用層次圖作為描繪軟件結構的文檔。結構圖作為文檔并不很合適，因為圖上包含的信息太多有時反而降低了清晰程度。但是，利用IPO圖或數據字典中的信息得到模塊調用時傳遞的信息，從而由層次圖導出結構圖的過程，卻可以作為檢查設計正確性和評價模塊獨立性的好方法。傳送的每個數據元素都是完成模塊功能所必須的嗎?反之，完成模塊功能必須的每個數據元素都傳送來了嗎?所有

19、數據元素都只和單一的功能有關嗎?如果發現結構圖上模塊間的聯系不容易解釋，則應該考慮是否設計上有問題。50結構圖(SC)舉例 醫院管理系統門診管理藥房管理藥庫管理病房管理財務管理處方掛號處理掛號費總計掛號單掛號費總計出庫處理進藥管理病歷管理處方管理常規處理51酒店管理信息系統功能結構圖H M I S收銀管理子系統收銀管理子系統收銀管理子系統客人登記預定登記客房處理歷史記錄客房查詢預定查詢餐桌安排菜單作業營業結帳匯總打印各類查詢初始設置客帳處理退房處理夜審處理客帳查詢報表打印大型零售商場管理信息系統功能結構圖TM M I S系統維護POS系統零售實時系統商品進貨管理商品批發管理商品庫存管理商品及商

20、品帳管理顧客管理連鎖店管理財務管理人事工資管理計劃統計管理經理查詢5.5 面向數據流的設計方法（又稱為SD：Structural Design)基本思想： DFD System Hierarchy 5.1、Data Flow 的分類 變換流(Transform Flow)：Internal representationInformationTransform flowOutgoingflowIncomingflowExternal representationTime事實上所有信息流都可歸結為變換流543. 面向數據流的設計方法 事務流(Transaction Flow) TTransacti

21、onrequest Action paths T = Call one of the several subroutines depending on the type of the incoming transaction request.當信息流具有明顯的“發射中心”時，可歸結為事務流。55(3)、軟件結構的表達工具：結構圖（SC圖）結構圖反映程序中模塊之間的層次調用關系和聯系：它以特定的符號表示模塊、模塊間的調用關系和模塊間信息的傳遞 模塊：模塊用矩形框表示，并用模塊的名字標記它。3. 面向數據流的設計方法56 模塊的調用關系和接口：模塊之間用單向箭頭聯結，箭頭從調用模塊指向被調用模塊。

22、3. 面向數據流的設計方法57 模塊間的信息傳遞：當一個模塊調用另一個模塊時，調用模塊把數據或控制信息傳送給被調用模塊，以使被調用模塊能夠運行。而被調用模塊在執行過程中又把它產生的數據或控制信息回送給調用模塊3. 面向數據流的設計方法58 在模塊A的箭頭尾部標以一個菱形符號，表示模塊A有條件地調用另一個模塊B。當一個在調用箭頭尾部標以一個弧形符號，表示模塊A反復調用模塊C和模塊D。3. 面向數據流的設計方法59(4)、SD的總體過程：“變換”“事物”精化數據流圖流類型區分事物中心和數據接收通路區分輸入和輸出分支映射成事務結構映射成變換結構用啟發式設計規則精化軟件結構導出接口描述和全程數據結構復

23、 查詳細設計變換分析事物分析優化的前題是：“Get it to work, then make it fast.”3. 面向數據流的設計方法605.2、分析設計案例變換分析例：汽車數字儀表板的設計功能： 通過模 - 數轉換實現傳感器和微處理機接口； 在發光二極管面板上顯示數據； 指示每小時英里數(mph),行駛的里程，每加侖油行駛的英里數(mpg)等等； 指示加速或減速； 如果車速超過55mph ,則發出警告鈴聲。3. 面向數據流的設計方法61第一步：DFD的分界，先分出I、P、O三塊燃料流 傳感器信號SPS旋轉信號讀旋轉信號收集和求平均確定加/減速轉換成轉/分計算里程計算mph,超速值產生加/減速顯示計算燃料消耗計算gph讀和校核產生mpg顯示產生mph顯示發出鈴聲產生里程顯示SPSSPS箭頭指示燃燒流上箭頭水平線下箭頭rpmrpmgphmphmpgmph超速值英里顯示鈴聲mph顯示mpg顯示3. 面向數據流的設計方法62一般問題