軟件設計基本概念.ppt

1、a,1,第2章 軟件設計基本概念,2.1 設計過程 2.2 設計原理 2.3 啟發(fā)規(guī)則,a,2,軟件設計宣言：Mitch Kapor “什么是設計？設計是你站在兩個世界技術世界和人類的目標世界而你嘗試將這兩個世界結合在一起”。 羅馬建筑批評家Vitruvius提出的觀念： “設計良好的建筑應該展示出堅固、適用和令人賞心悅目”。,a,3,設計階段： 從工程管理的角度，可以將軟件設計分為概要設計階段和詳細設計階段。 從技術的角度，傳統(tǒng)的結構化方法將軟件設計劃分為體系結構設計、數(shù)據(jù)設計、接口設計和過程設計4部分。 面向對象方法則將軟件設計劃分為體系結構設計、類設計/數(shù)據(jù)設計、接口設計和構件級設計4部

2、分。,a,4,a,5,結構化設計和結構化分析的關系：,a,6,總體設計過程：首先尋找實現(xiàn)目標系統(tǒng)的各種不同的方案；然后分析員從這些供選擇的方案中選取若干個合理的方案，從中選出一個最佳方案向用戶和使用部門負責人推薦；分析員應該進一步為這個最佳方案設計軟件結構，進行必要的數(shù)據(jù)庫設計，確定測試要求并且制定測試計劃。 必要性：總體設計可以站在全局高度上，花較少成本，從較抽象的層次上分析對比多種可能的系統(tǒng)實現(xiàn)方案和軟件結構，從中選出最佳方案和最合理的軟件結構，從而用較低成本開發(fā)出較高質量的軟件系統(tǒng)。,a,7,5.1 設計過程,由兩個主要階段組成： 系統(tǒng)設計階段，確定系統(tǒng)的具體實現(xiàn)方案 設想供選擇的方案

3、選取合理的方案 推薦最佳方案 結構設計階段，確定軟件結構 功能分解 設計軟件結構 設計數(shù)據(jù)庫,制定測試計劃 書寫文檔 審查和復審,a,8,典型的總體設計過程包括下述9個步驟： 1. 設想供選擇的方案 根據(jù)需求分析階段得出的數(shù)據(jù)流圖考慮各種可能的實現(xiàn)方案，力求從中選出最佳方案。 2. 選取合理的方案 從前一步得到的一系列供選擇的方案中選取若干個合理的方案。對每個合理的方案分析員都應該準備下列4份資料： 系統(tǒng)流程圖； 組成系統(tǒng)的物理元素清單； 成本/效益分析； 實現(xiàn)這個系統(tǒng)的進度計劃。,a,9,3. 推薦最佳方案 分析員應該綜合分析對比各種合理方案的利弊，推薦一個最佳的方案，并且為推薦的方案制定詳

4、細的實現(xiàn)計劃。 4. 功能分解 首先進行結構設計，然后進行過程設計。 結構設計確定程序由哪些模塊組成，以及這些模塊之間的關系；過程設計確定每個模塊的處理過程。 結構設計是總體設計階段的任務，過程設計是詳細設計階段的任務。,a,10,5. 設計軟件結構 通常程序中的一個模塊完成一個適當?shù)淖庸δ?。應該把模塊組織成良好的層次系統(tǒng)。軟件結構可以用層次圖或結構圖來描繪。 如果數(shù)據(jù)流圖已經(jīng)細化到適當?shù)膶哟?，則可以直接從數(shù)據(jù)流圖映射出軟件結構，這就是面向數(shù)據(jù)流的設計方法。 6. 設計數(shù)據(jù)庫 對于需要使用數(shù)據(jù)庫的那些應用系統(tǒng)，軟件工程師應該在需求分析階段所確定的系統(tǒng)數(shù)據(jù)需求的基礎上，進一步設計數(shù)據(jù)庫。,a,1

5、1,7. 制定測試計劃 在軟件開發(fā)的早期階段考慮測試問題，能促使軟件設計人員在設計時注意提高軟件的可測試性。 8. 書寫文檔 應該用正式的文檔記錄總體設計的結果，在這個階段應該完成的文檔通常有下述幾種： (1) 系統(tǒng)說明； (2) 用戶手冊；(3) 測試計劃； (4) 詳細的實現(xiàn)計劃；(5) 數(shù)據(jù)庫設計結果。 9. 審查和復審 最后應該對總體設計的結果進行嚴格的技術審查和管理復審。,a,12,5.2 設計原理 5.2.1 模塊化,模塊：是由邊界元素限定的相鄰程序元素的序列，而且有一個總體標識符代表它。 模塊化：就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起

6、來構成一個整體，可以完成指定的功能滿足用戶的需求。,a,13,為什么要模塊化？ 模塊化是為了使一個復雜的大型程序能被人的智力所管理，軟件應該具備的惟一屬性。 如果一個大型程序僅由一個模塊組成，它將很難被人所理解。,a,14,模塊化的根據(jù)： 如果C(P1)C(P2)，顯然E(P1)E(P2) 根據(jù)人類解決一般問題的經(jīng)驗， C(P1+P2)C(P1)+C(P2) 綜上所述，得到下面的不等式 E(P1+P2)E(P1)+E(P2),a,15,每個程序都相應地有一個最適當?shù)哪K數(shù)目M，使得系統(tǒng)的開發(fā)成本最小。,模塊化和軟件成本,a,16,模塊化的作用： 采用模塊化原理可以使軟件結構清晰，不僅容易設計也

7、容易閱讀和理解。 模塊化使軟件容易測試和調試，因而有助于提高軟件的可靠性。 模塊化能夠提高軟件的可修改性。 模塊化也有助于軟件開發(fā)工程的組織管理。,a,17,5.2.2 抽象,抽象：現(xiàn)實世界中一定事物、狀態(tài)或過程之間總存在著某些相似的方面(共性)。把這些相似的方面集中和概括起來，暫時忽略它們之間的差異，這就是抽象。 抽象就是抽出事物本質特性而暫時不考慮細節(jié)。 “抽象是人類處理復雜問題的基本方法之一?！?Grady Boach,a,18,一般抽象過程： 處理復雜系統(tǒng)的惟一有效的方法是用層次的方式構造和分析它。 一個復雜的動態(tài)系統(tǒng)首先可以用一些高級的抽象概念構造和理解，這些高級概念又可以用一些較低

8、級的概念構造和理解，如此進行下去，直至最低層次的具體元素。 例：過程抽象、數(shù)據(jù)抽象,開(行為抽象）+ 門(數(shù)據(jù)抽象),a,19,形體,衣著,性格,抽象,抽象例子,外表,a,20,軟件工程抽象過程： 軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。 在可行性研究階段，軟件作為系統(tǒng)的一個完整部件； 在需求分析期間，軟件解法是使用在問題環(huán)境內熟悉的方式描述的； 當由總體設計向詳細設計過渡時，抽象的程度也就隨之減少了； 最后，當源程序寫出來以后，也就達到了抽象的最低層。,a,21,5.2.3 逐步求精,逐步求精：為了能集中精力解決主要問題而盡量推遲對問題細節(jié)的考慮。逐步求精是人類解決復雜問題時

9、采用的基本方法，也是許多軟件工程技術的基礎。 Miller法則：一個人在任何時候都只能把注意力集中在（72）個知識塊上。,a,22,逐步求精,外表,形體,衣著,性格,頭發(fā),臉形,領帶,抽象,逐步求精的例子,a,23,例：用篩選法求100以內的素數(shù)。所謂的篩選法，就是從2到100中去掉2，3，5，7的倍數(shù)，剩下的就是100以內的素數(shù)。 首先按程序功能寫出一個框架 main() 建立2到100的數(shù)組A ，其中Aii；.1 建立2到10的素數(shù)表B ，存放2到10以內的素數(shù)；.2 若Aii是B 中任一數(shù)的倍數(shù)，則剔除Ai；.3 輸出A 中所有沒有被剔除的數(shù)；.4 ,a,24,上述框架中每一個加工語句都

10、可進一步細化 main() /*建立2到100的數(shù)組A ，其中Aii*/ .1 for （i = 2；i = 100；i+）Ai = i； /* 建立2到10的素數(shù)表B ，存放2到10以內的素數(shù)*/ .2 B1 =2； B2 = 3； B3 = 5； B4 = 7； /*若Aii是B 中任一數(shù)的倍數(shù)，則剔除Ai*/ .3 for （j = 1； j = 4； j+） 檢查A所有數(shù)能否被Bj整除并將其從A剔除；.3.1 /*輸出A 中所有沒有被剔除的數(shù)*/ .4 for （i = 2； i 25) module_3(); else module_4(); ,a,42,評價： 與結構化編程矛盾，生

11、成的代碼完全不可讀。 如果在一個模塊中對一個全局變量的聲明進行修改，必須修改能夠訪問該全局變量的每一個模塊。 公共環(huán)境耦合的模塊難于重用，必須提供一個全局變量的清單。 即使模塊本身不改變，它和產(chǎn)品中其他模塊之間公共環(huán)境耦合的實例數(shù)也會變化非常大。 潛在危險很大。模塊暴露出必需要更多的數(shù)據(jù)，難以控制數(shù)據(jù)存取，而且會導致計算機犯罪。 有些情況下公共環(huán)境耦合更好。,a,43,函數(shù)可重入的概念,可重入函數(shù)也可以這樣理解，重入即表示重復進入，首先它意味著這個函數(shù)可以被中斷，其次意味著它除了使用自己棧上的變量以外不依賴于任何環(huán)境（包括static），這樣的函數(shù)就是purecode（純代碼）可重入，可以允許

12、有該函數(shù)的多個副本在運行，由于它們使用的是分離的棧，所以不會互相干擾。如果確實需要訪問全局變量（包括static），一定要注意實施互斥手段。可重入函數(shù)在并行運行環(huán)境中非常重要，但是一般要為訪問全局變量付出一些性能代價,a,44,(6) 內容耦合(content coupling) 最高程度的耦合是內容耦合。如果出現(xiàn)下列情況之一，兩個模塊間就發(fā)生了內容耦合： 一個模塊訪問另一個模塊的內部數(shù)據(jù)； 一個模塊不通過正常入口轉到另一個模塊的內部； 兩個模塊有一部分程序代碼重疊； 一個模塊有多個入口。,a,45,耦合是影響軟件復雜程度的一個重要因素。 應該采取下述設計原則： 盡量使用數(shù)據(jù)耦合， 少用控制耦

13、合和特征耦合， 限制公共環(huán)境耦合的范圍， 完全不用內容耦合。,a,46,2. 內聚 內聚：標志一個模塊內各個元素彼此結合的緊密程度，它是信息隱藏和局部化概念的自然擴展。簡單地說，理想內聚的模塊只做一件事情。 要求：設計時應該力求做到高內聚，通常中等程度的內聚也是可以采用的，而且效果和高內聚相差不多；但是，低內聚不要使用。 內聚和耦合是密切相關的，模塊內的高內聚往往意味著模塊間的松耦合。實踐表明內聚更重要，應該把更多注意力集中到提高模塊的內聚程度上。,a,47,內聚程度的度量： (1) 偶然內聚(coincidental cohesion) 如果一個模塊完成一組任務，這些任務彼此間即使有關系，關

14、系也是很松散的，就叫做偶然內聚。,a,48,評價： 模塊內各元素之間沒有實質性聯(lián)系，很可能在一種應用場合需要修改這個模塊，在另一種應用場合又不允許這種修改，從而陷入困境； 可理解性差，可維護性產(chǎn)生退化； 模塊是不可重用的。 解決方案： 將模塊分成更小的模塊，每個小模塊執(zhí)行一個操作。,a,49,(2) 邏輯內聚(logical cohesion) 如果一個模塊完成的任務在邏輯上屬于相同或相似的一類，則稱為邏輯內聚。,a,50,評價： 接口難以理解，造成整體上不易理解； 完成多個操作的代碼互相糾纏在一起，即使局部功能的修改有時也會影響全局，導致嚴重的維護問題； 難以重用。 解決方案： 模塊分解。,

15、a,51,a,52,(3) 時間內聚(temporal cohesion) 如果一個模塊包含的任務必須在同一段時間內執(zhí)行，就叫時間內聚。,a,53,評價： 時間關系在一定程度上反映了程序某些實質，所以時間內聚比邏輯內聚好一些。 模塊內操作之間的關系很弱，與其他模塊的操作卻有很強的關聯(lián)。 時間內聚的模塊不太可能重用。,a,54,(4) 過程內聚(procedural cohesion) 如果一個模塊內的處理元素是相關的，而且必須以特定次序執(zhí)行，則稱為過程內聚。 使用程序流程圖作為工具設計軟件時，常常通過研究流程圖確定模塊的劃分，這樣得到的往往是過程內聚的模塊。,a,55,a,56,評價： 比時間

16、內聚好，至少操作之間是過程關聯(lián)的。 仍是弱連接，不太可能重用模塊。 解決方案： 分割為單獨的模塊，每個模塊執(zhí)行一個操作。,a,57,(5) 通信內聚(communicational cohesion) 如果模塊中所有元素都使用同一個輸入數(shù)據(jù)和(或)產(chǎn)生同一個輸出數(shù)據(jù)，則稱為通信內聚。即在同一個數(shù)據(jù)結構上操作。 評價： 模塊中各操作緊密相連，比過程內聚更好。 不能重用。 解決方案： 分成多個模塊，每個模塊執(zhí)行一個操作。,a,58,a,59,(6) 順序內聚(sequential cohesion) 如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執(zhí)行，則稱為順序內聚。 評價：

17、根據(jù)數(shù)據(jù)流圖劃分模塊時，通常得到順序內聚的模塊，這種模塊彼此間的連接往往比較簡單。,a,60,(7) 功能內聚(functional cohesion) 如果模塊內所有處理元素屬于一個整體，完成一個單一的功能，則稱為功能內聚。功能內聚是最高程度的內聚。 評價： 模塊可重用，應盡可能重用； 可隔離錯誤，維護更容易； 擴充產(chǎn)品功能時更容易。,a,61,七種內聚的優(yōu)劣評分結果： 高內聚：功能內聚 10分 順序內聚 9分 中內聚：通信內聚 7分 過程內聚 5分 低內聚：時間內聚 3分 邏輯內聚 1分 偶然內聚 0分 設計時力爭做到高內聚，并且能夠辨認出低內聚的模塊。,a,62,5.3 啟發(fā)規(guī)則,1.

18、改進軟件結構提高模塊獨立性 通過模塊分解或合并，降低耦合提高內聚。 兩個方面： 模塊功能完善化。一個完整的模塊包含： 執(zhí)行規(guī)定的功能的部分 出錯處理的部分 返回一個“結束標志” 消除重復功能，改善軟件結構。 完全相似 局部相似,a,63,a,64,2. 模塊規(guī)模應該適中 經(jīng)驗表明，一個模塊的規(guī)模不應過大，最好能寫在一頁紙內。通常規(guī)定50100行語句，最多不超過500行。數(shù)字只能作為參考，根本問題是要保證模塊的獨立性。 過大的模塊往往是由于分解不充分，但是進一步分解必須符合問題結構，一般說來，分解后不應該降低模塊獨立性。 過小的模塊開銷大于有效操作，而且模塊數(shù)目過多將使系統(tǒng)接口復雜。,a,65,3. 深度、寬度、扇出和扇入都應適當 深度：軟件結構中控制的層數(shù)，它往往能粗略地標志一個系統(tǒng)的大小和復雜程度。 寬度：軟件結構內同一個層次上