1、第11章 面向對象設計 (OOD)11.1 面向對象設計的準那么面向對象設計的準那么11.2 啟發規那么啟發規那么11.3 軟件重用軟件重用11.4 系統分解系統分解11.5 設計問題域子系統設計問題域子系統11.6 設計人機交互子系統設計人機交互子系統11.7 設計義務管理子系統設計義務管理子系統11.8 設計數據管理子系統設計數據管理子系統11.9 設計類中的效力設計類中的效力11.10 設計關聯設計關聯11.11 設計優化設計優化分析是提取和整理用戶需求，并建立問題域準確分析是提取和整理用戶需求，并建立問題域準確模型的過程。模型的過程。設計是把分析階段得到的需求轉變成符合本錢和設計是把分

2、析階段得到的需求轉變成符合本錢和質量要求的、籠統的系統實現方案的過程。質量要求的、籠統的系統實現方案的過程。從面向對象分析到面向對象設計從面向對象分析到面向對象設計(OOD)，是一個，是一個逐漸擴展模型的過程。面向對象設計就是用面向逐漸擴展模型的過程。面向對象設計就是用面向對象觀念建立求解域模型的過程。對象觀念建立求解域模型的過程。分析和設計活動是一個多次反復迭代的過程。面分析和設計活動是一個多次反復迭代的過程。面向對象方法學在概念和表示方法上的一致性，保向對象方法學在概念和表示方法上的一致性，保證了在各項開發活動之間的平滑證了在各項開發活動之間的平滑(無縫無縫)過渡。過渡。面向對象設計可再細

3、分為系統設計和對象設計。面向對象設計可再細分為系統設計和對象設計。系統設計確定實現系統的戰略和目的系統的高層系統設計確定實現系統的戰略和目的系統的高層構造。對象設計確定解空間中的類、關聯、接口構造。對象設計確定解空間中的類、關聯、接口方式及實現效力的算法。方式及實現效力的算法。優秀的設計，是權衡了各種要素，從而使得系統在優秀的設計，是權衡了各種要素，從而使得系統在其整個生命周期中的總開銷最小的設計。其整個生命周期中的總開銷最小的設計。對大多數軟件系統而言，對大多數軟件系統而言，60%以上的軟件費用都用以上的軟件費用都用于軟件維護，因此，優秀軟件設計的一個主要特點于軟件維護，因此，優秀軟件設計的

4、一個主要特點就是容易維護。就是容易維護。11.1 面向對象設計的準那么面向對象設計的準那么面向對象設計準那么面向對象設計準那么1. 模塊化模塊化對象是把數據構造和操作這些數據的方法嚴密地結合在一對象是把數據構造和操作這些數據的方法嚴密地結合在一同所構成的模塊。面向對象軟件開發方式支持了把系統分同所構成的模塊。面向對象軟件開發方式支持了把系統分解成模塊的設計原理：解成模塊的設計原理：2. 籠統籠統過程籠統過程籠統數據籠統。類實踐上是一種籠統數據類型，它對外開放的數據籠統。類實踐上是一種籠統數據類型，它對外開放的公共接口構成了類的規格闡明公共接口構成了類的規格闡明(即協議即協議)，這種接口規定了，

5、這種接口規定了外界可以運用的合法操作符，利用這些操作符可以對類實外界可以運用的合法操作符，利用這些操作符可以對類實例中包含的數據進展操作。例中包含的數據進展操作。參數化籠統，是指當描畫類的規格闡明時并不詳細指定所參數化籠統，是指當描畫類的規格闡明時并不詳細指定所要操作的數據類型，而是把數據類型作為參數。例如，要操作的數據類型，而是把數據類型作為參數。例如，C+言語提供的言語提供的“模板機制就是一種參數化籠統機制。模板機制就是一種參數化籠統機制。3. 信息隱藏信息隱藏在面向對象方法中，信息隱藏經過對象的封裝性實現：類在面向對象方法中，信息隱藏經過對象的封裝性實現：類構造分別了接口與實現，從而支持

6、了信息隱藏。構造分別了接口與實現，從而支持了信息隱藏。4. 弱耦合弱耦合耦合指一個軟件構造內不同模塊之間互連的嚴密程度。在耦合指一個軟件構造內不同模塊之間互連的嚴密程度。在面向對象方法中，對象是最根本的模塊，因此，耦合主要面向對象方法中，對象是最根本的模塊，因此，耦合主要指不同對象之間相互關聯的嚴密程度。指不同對象之間相互關聯的嚴密程度。弱耦合是優秀設計的一個重要規范，由于這有助于使得系弱耦合是優秀設計的一個重要規范，由于這有助于使得系統中某一部分的變化對其他部分的影響降到最低程度。在統中某一部分的變化對其他部分的影響降到最低程度。在理想情況下，對某一部分的了解、測試或修正，無須涉及理想情況下

7、，對某一部分的了解、測試或修正，無須涉及系統的其他部分。系統的其他部分。當然，對象不能夠是完全孤立的，當兩個對象必需相互聯當然，對象不能夠是完全孤立的，當兩個對象必需相互聯絡相互依賴時，應該經過類的協議絡相互依賴時，應該經過類的協議(即公共接口即公共接口)實現耦合，實現耦合，而不應該依賴于類的詳細實現細節。而不應該依賴于類的詳細實現細節。普通說來，對象之間的耦合可分為兩大類：普通說來，對象之間的耦合可分為兩大類：(1) 交互耦合交互耦合 盡能夠松散盡能夠松散交互耦合交互耦合 對象之間的耦合經過音訊銜接來實現。對象之間的耦合經過音訊銜接來實現。為使交互耦合盡能夠松散，應該遵守下述準那么：為使交互

8、耦合盡能夠松散，應該遵守下述準那么：a) 盡量降低音訊銜接的復雜程度。應該盡量減少音訊中包盡量降低音訊銜接的復雜程度。應該盡量減少音訊中包含的參數個數，降低參數的復雜程度。含的參數個數，降低參數的復雜程度。b) 減少對象發送減少對象發送(或接納或接納)的音訊數。的音訊數。(2) 承繼耦合承繼耦合 盡能夠嚴密盡能夠嚴密承繼是普通化類與特殊類之間耦合的一種方式，應該提高承繼是普通化類與特殊類之間耦合的一種方式，應該提高承繼耦合程度。從本質上看，經過承繼關系結合起來的基承繼耦合程度。從本質上看，經過承繼關系結合起來的基類和派生類，構成了系統中粒度更大的模塊。因此，它們類和派生類，構成了系統中粒度更大

9、的模塊。因此，它們彼此之間應該結合得越嚴密越好。彼此之間應該結合得越嚴密越好。為獲得嚴密的承繼耦合，特殊類應該確實是對它的普通化為獲得嚴密的承繼耦合，特殊類應該確實是對它的普通化類的一種詳細化。因此，假設一個派生類摒棄了它基類的類的一種詳細化。因此，假設一個派生類摒棄了它基類的許多屬性，那么它們之間是松耦合的。在設計時應該使特許多屬性，那么它們之間是松耦合的。在設計時應該使特殊類盡量多承繼并運用其普通化類的屬性和效力，從而更殊類盡量多承繼并運用其普通化類的屬性和效力，從而更嚴密地耦合到其普通化類。嚴密地耦合到其普通化類。5. 強內聚強內聚內聚衡量一個模塊內各個元素彼此結合的嚴密程度。也可內聚衡

10、量一個模塊內各個元素彼此結合的嚴密程度。也可以把內聚定義為：設計中運用的一個構件內的各個元素，以把內聚定義為：設計中運用的一個構件內的各個元素，對完成一個定義明確的目的所做出的奉獻程度。在設計時對完成一個定義明確的目的所做出的奉獻程度。在設計時應該力求做到高內聚。在面向對象設計中存在下述應該力求做到高內聚。在面向對象設計中存在下述3種內聚。種內聚。1 效力內聚。一個效力應該完成一個且僅完成一個功能。效力內聚。一個效力應該完成一個且僅完成一個功能。2 類內聚。設計類的原那么是，一個類應該只需一個用類內聚。設計類的原那么是，一個類應該只需一個用途，它的屬性和效力應該是高內聚的。類的屬性和效力應途，

11、它的屬性和效力應該是高內聚的。類的屬性和效力應該全都是完成該類對象的義務所必需的，其中不包含無用該全都是完成該類對象的義務所必需的，其中不包含無用的屬性或效力。假設某個類有多個用途，通常應該把它分的屬性或效力。假設某個類有多個用途，通常應該把它分解成多個公用的類。解成多個公用的類。3 普通普通-特殊內聚。設計出的普通特殊內聚。設計出的普通-特殊構造，應該符合特殊構造，應該符合多數人的概念，更準確地說，這種構造應該是對相應的領多數人的概念，更準確地說，這種構造應該是對相應的領域知識的正確抽取。域知識的正確抽取。嚴密的承繼耦合與高度的普通嚴密的承繼耦合與高度的普通-特殊內聚是一致的。特殊內聚是一致

12、的。6. 可重用可重用軟件重用是提高軟件開發消費率和目的系統質量的軟件重用是提高軟件開發消費率和目的系統質量的重要途徑。重用根本上從設計階段開場。重要途徑。重用根本上從設計階段開場。重用有兩方面的含義：重用有兩方面的含義： 一是盡量運用已有的類一是盡量運用已有的類(包括開發環境提供的類庫，包括開發環境提供的類庫，及以往開發類似系統時創建的類及以往開發類似系統時創建的類)；二是假設確實需求創建新類，那么在設計這些新類二是假設確實需求創建新類，那么在設計這些新類的協議時，應該思索未來的可反復運用性。的協議時，應該思索未來的可反復運用性。設計結果應該明晰易懂設計結果應該明晰易懂1 用詞一致。應該使名

13、字與它所代表的事物一致，用詞一致。應該使名字與它所代表的事物一致，而且應該盡量運用人們習慣的名字。不同類中類似效而且應該盡量運用人們習慣的名字。不同類中類似效力的名字應該一樣。力的名字應該一樣。2 運用已有的協議。假設開發同一軟件的其他設計運用已有的協議。假設開發同一軟件的其他設計人員曾經建立了類的協議，或者在所運用的類庫中已人員曾經建立了類的協議，或者在所運用的類庫中已有相應的協議，那么應該運用這些已有的協議。有相應的協議，那么應該運用這些已有的協議。3 減少音訊方式的數目。假設已有規范的音訊協議，減少音訊方式的數目。假設已有規范的音訊協議，設計人員應該遵守這些協議。假設確需本人建立音訊設計

14、人員應該遵守這些協議。假設確需本人建立音訊協議，那么應該盡量減少音訊方式的數目，只需能夠，協議，那么應該盡量減少音訊方式的數目，只需能夠，就使音訊具有一致的方式，以利于讀者了解。就使音訊具有一致的方式，以利于讀者了解。4 防止模糊的定義。一個類的用途應該是有限的，防止模糊的定義。一個類的用途應該是有限的，而且應該從類名可以較容易地推想出它的用途。而且應該從類名可以較容易地推想出它的用途。11.2 啟發規那么啟發規那么2. 普通普通-特殊構造的深度應適當特殊構造的深度應適當普通說來，在一個中等規模普通說來，在一個中等規模(大約包含大約包含100個類個類)的系的系統中，類等級層次數應堅持為統中，類

15、等級層次數應堅持為72。不應該僅僅從方。不應該僅僅從方便編碼的角度出發隨意創建派生類，應該使普通便編碼的角度出發隨意創建派生類，應該使普通-特特殊構造與領域知識或常識堅持一致。殊構造與領域知識或常識堅持一致。3. 設計簡單的類設計簡單的類應該盡量設計小而簡單的類，以便于開發和管理。為應該盡量設計小而簡單的類，以便于開發和管理。為使類堅持簡單，應該留意以下幾點。使類堅持簡單，應該留意以下幾點。(1) 防止包含過多的屬性。防止包含過多的屬性。 (2) 有明確的定義。分配給每個類的義務應該簡單。有明確的定義。分配給每個類的義務應該簡單。(3) 盡量簡化對象之間的協作關系。盡量簡化對象之間的協作關系。

16、 (4) 不要提供太多效力。不要提供太多效力。4. 運用簡單的協議運用簡單的協議閱歷闡明，經過復雜音訊相互關聯的對象是緊耦合的，閱歷闡明，經過復雜音訊相互關聯的對象是緊耦合的，對一個對象的修正往往導致其他對象的修正。對一個對象的修正往往導致其他對象的修正。5. 運用簡單的效力運用簡單的效力面向對象設計出來的類中的效力通常都很小，可以用面向對象設計出來的類中的效力通常都很小，可以用僅含一個動詞和一個賓語的簡單句子描畫它的功能。僅含一個動詞和一個賓語的簡單句子描畫它的功能。設法分解或簡化復雜的效力。設法分解或簡化復雜的效力。6. 把設計變動減至最小把設計變動減至最小通常，設計的質量越高，設計結果堅

17、持不變的時間也通常，設計的質量越高，設計結果堅持不變的時間也越長。即使出現必需修正設計的情況，也應該使修正越長。即使出現必需修正設計的情況，也應該使修正的范圍盡能夠小。理想的設計變動曲線如圖的范圍盡能夠小。理想的設計變動曲線如圖11.1所示。所示。在設計的早期階段，變動較大，隨著時間推移，設在設計的早期階段，變動較大，隨著時間推移，設計方案日趨成熟，改動也越來越小了。圖計方案日趨成熟，改動也越來越小了。圖11.1中的峰中的峰值與出現設計錯誤或發生非預期變動的情況相對應。值與出現設計錯誤或發生非預期變動的情況相對應。峰值越高，闡明設計質量越差，可重用性也越差。峰值越高，闡明設計質量越差，可重用性

18、也越差。圖圖11.1 理想的設計變動情況理想的設計變動情況1. 重用重用重用也叫再用或復用，是指同一事物不作修正或稍加重用也叫再用或復用，是指同一事物不作修正或稍加改動就多次反復運用。改動就多次反復運用。軟件重用可分為以下軟件重用可分為以下3個層次：個層次：(1) 知識重用知識重用(例如，軟件工程知識的重用例如，軟件工程知識的重用)。(2) 方法和規范的重用方法和規范的重用(例如，面向對象方法或國家制例如，面向對象方法或國家制定的軟件開發規范的重用定的軟件開發規范的重用)。(3) 軟件成分的重用。軟件成分的重用。前兩個重用層次屬于知識工程研討的范疇，本節僅討前兩個重用層次屬于知識工程研討的范疇

19、，本節僅討論軟件成分重用問題。論軟件成分重用問題。11.3 軟件重用軟件重用 11.3.1 概述概述2. 軟件成分的重用級別軟件成分的重用級別軟件成分的重用可以進一步劃分成以下軟件成分的重用可以進一步劃分成以下3個級別：個級別：(1) 代碼重用代碼重用 采用以下幾種方式中的任何一種：采用以下幾種方式中的任何一種： 源代碼剪貼源代碼剪貼 源代碼包含源代碼包含 承繼承繼(2) 設計結果重用設計結果重用重用某個軟件系統的設計模型重用某個軟件系統的設計模型(即求解域模型即求解域模型)。(3) 分析結果重用分析結果重用重用某個系統的分析模型。重用某個系統的分析模型。3. 典型的可重用軟件成分典型的可重用

20、軟件成分更詳細地說，能夠被重用的軟件成分主要有以下更詳細地說，能夠被重用的軟件成分主要有以下10種：種：1 工程方案。軟件工程方案的根本構造和許多內容工程方案。軟件工程方案的根本構造和許多內容例如，軟件質量保證方案都是可以跨工程重用的。例如，軟件質量保證方案都是可以跨工程重用的。2 本錢估計。由于在不同工程中經常含有類似的功本錢估計。由于在不同工程中經常含有類似的功能，所以有能夠在只做極少修正或根本不做修正的情能，所以有能夠在只做極少修正或根本不做修正的情況下，重用對該功能的本錢估計結果。況下，重用對該功能的本錢估計結果。3 體系構造。即使在思索不同的運用領域時，也很體系構造。即使在思索不同的

21、運用領域時，也很少有截然不同的程序和數據體系構造。因此，有能夠少有截然不同的程序和數據體系構造。因此，有能夠創建一組類屬的體系構造模板例如，事務處置體系創建一組類屬的體系構造模板例如，事務處置體系構造，并把那些模板作為可重用的設計框架。通常構造，并把那些模板作為可重用的設計框架。通常把類屬的體系構造模板稱為領域體系構造。把類屬的體系構造模板稱為領域體系構造。4 需求模型和規格闡明。類和對象的模型及規格闡需求模型和規格闡明。類和對象的模型及規格闡明是明顯的重用的候選者；用傳統軟件工程方法開發明是明顯的重用的候選者；用傳統軟件工程方法開發的分析模型例如，數據流圖，也是可重用的。的分析模型例如，數據

22、流圖，也是可重用的。5 設計。用傳統方法開發的體系構造、數據、接口和過設計。用傳統方法開發的體系構造、數據、接口和過程設計結果，是重用的候選者，更常見的是，系統和對象程設計結果，是重用的候選者，更常見的是，系統和對象設計是可重用的。設計是可重用的。6 源代碼。用兼容的程序設計言語書寫的、經過驗證的源代碼。用兼容的程序設計言語書寫的、經過驗證的程序構件，是重用的候選者。程序構件，是重用的候選者。7 用戶文檔和技術文檔。即使針對的運用是不同的，也用戶文檔和技術文檔。即使針對的運用是不同的，也經常有能夠重用用戶文檔和技術文檔的大部分。經常有能夠重用用戶文檔和技術文檔的大部分。8 用戶界面。這能夠是最

23、廣泛被重用的軟件成分，用戶界面。這能夠是最廣泛被重用的軟件成分，GUI圖形用戶界面軟件經常被重用。由于它可占到一個運圖形用戶界面軟件經常被重用。由于它可占到一個運用程序的用程序的60%代碼量，因此，重用的效果非常顯著。代碼量，因此，重用的效果非常顯著。9 數據。在大多數經常被重用的軟件成分中，被重用的數據。在大多數經常被重用的軟件成分中，被重用的數據包括：數據包括： 內部表、列表和記錄構造，以及文件和完好的內部表、列表和記錄構造，以及文件和完好的數據庫。數據庫。10 測試用例。一旦設計或代碼構件將被重用，相關的測試用例。一旦設計或代碼構件將被重用，相關的測試用例應該測試用例應該“附屬于它們也被

24、重用。附屬于它們也被重用。面向對象技術中的面向對象技術中的“類，是比較理想的可重用軟構類，是比較理想的可重用軟構件，無妨稱之為類構件。類構件有件，無妨稱之為類構件。類構件有3種重用方式，種重用方式，分別是實例重用、承繼重用和多態重用。下面進分別是實例重用、承繼重用和多態重用。下面進一步講述與類構件有關的內容。一步講述與類構件有關的內容。11.3.2 類構件類構件1. 可重用軟構件應具備的特點可重用軟構件應具備的特點模塊獨立性強。具有單一、完好的功能，且經過反模塊獨立性強。具有單一、完好的功能，且經過反復測試被確認是正確的。它應該是一個不受或復測試被確認是正確的。它應該是一個不受或很少受外界干擾

25、的封裝體，其內部實如今外面很少受外界干擾的封裝體，其內部實如今外面是不可見的。是不可見的。(2) 具有高度可塑性。可重用的軟構件必需具有高度具有高度可塑性。可重用的軟構件必需具有高度可裁剪性，也就是說，必需提供為順應特定需可裁剪性，也就是說，必需提供為順應特定需求而擴展或修正已有構件的機制，而且運用非求而擴展或修正已有構件的機制，而且運用非常簡一方便。常簡一方便。(3) 接口明晰、簡明、可靠。軟構件應該提供明晰、接口明晰、簡明、可靠。軟構件應該提供明晰、簡明、可靠的對外接口，而且還應該有詳盡的簡明、可靠的對外接口，而且還應該有詳盡的文檔闡明，以方便用戶運用。文檔闡明，以方便用戶運用。精心設計的

26、精心設計的“類根本上能滿足上述要求，可以以為類根本上能滿足上述要求，可以以為它是可重用軟構件的雛形。它是可重用軟構件的雛形。2. 類構件的重用方式類構件的重用方式(1) 實例重用實例重用由于類的封裝性，運用者無須了解實現細節就可以由于類的封裝性，運用者無須了解實現細節就可以運用適當的構造函數，按照需求創建類的實例。然運用適當的構造函數，按照需求創建類的實例。然后向所創建的實例發送適當的音訊，啟動相應的效后向所創建的實例發送適當的音訊，啟動相應的效力，完成需求完成的任務。這是最根本的重用方式。力，完成需求完成的任務。這是最根本的重用方式。此外，還可以用幾個簡單的對象作為類的成員創建此外，還可以用

27、幾個簡單的對象作為類的成員創建出一個更復雜的類，這是實例重用的另一種方式。出一個更復雜的類，這是實例重用的另一種方式。(2) 承繼重用承繼重用面向對象方法特有的承繼性提供了一種對已有的類構面向對象方法特有的承繼性提供了一種對已有的類構件進展裁剪的機制。當已有的類構件不能經過實例重件進展裁剪的機制。當已有的類構件不能經過實例重用完全滿足當前系統需求時，承繼重用提供了一種平用完全滿足當前系統需求時，承繼重用提供了一種平安地修正已有類構件，以便在當前系統中重用的手段。安地修正已有類構件，以便在當前系統中重用的手段。為提高承繼重用的效果，關鍵是設計一個合理的、具為提高承繼重用的效果，關鍵是設計一個合理

28、的、具有一定深度的類構件承繼層次構造。有一定深度的類構件承繼層次構造。. 每個子類在承繼父類的屬性和效力的根底上，只參每個子類在承繼父類的屬性和效力的根底上，只參與少量新屬性和新效力，這就不僅降低了每個類構件與少量新屬性和新效力，這就不僅降低了每個類構件的接口復雜度，表現出一個明晰的進化過程，提高了的接口復雜度，表現出一個明晰的進化過程，提高了每個子類的可了解性，而且為軟件開發人員提供了更每個子類的可了解性，而且為軟件開發人員提供了更多可重用的類構件。必要時應在領域專家協助下，建多可重用的類構件。必要時應在領域專家協助下，建立符合領域知識的承繼層次。立符合領域知識的承繼層次。. 為多態重用奠定

29、了良好根底。為多態重用奠定了良好根底。(3) 多態重用多態重用利用多態性不僅可以使對象的對外接口更加普通化利用多態性不僅可以使對象的對外接口更加普通化(基基類與派生類的許多對外接口是一樣的類與派生類的許多對外接口是一樣的)，從而降低了音，從而降低了音訊銜接的復雜程度，而且還提供了一種簡便可靠的軟訊銜接的復雜程度，而且還提供了一種簡便可靠的軟構件組合機制。系統運轉時，根據接納音訊的對象類構件組合機制。系統運轉時，根據接納音訊的對象類型，由多態性機制啟動正確的方法，去呼應一個普通型，由多態性機制啟動正確的方法，去呼應一個普通化的音訊，從而簡化了音訊界面和軟構件銜接過程。化的音訊，從而簡化了音訊界面

30、和軟構件銜接過程。為充分實現多態重用，在設計類構件時，應該把留意為充分實現多態重用，在設計類構件時，應該把留意力集中在以下一些能夠影響重用性的操作上：力集中在以下一些能夠影響重用性的操作上： 與表示方法有關的操作。與表示方法有關的操作。 與數據構造、數據大小等有關的操作。與數據構造、數據大小等有關的操作。 與外部設備有關的操作。例如，設備控制。與外部設備有關的操作。例如，設備控制。 實現算法在未來能夠會改良實現算法在未來能夠會改良(或改動或改動)的中心操作。的中心操作。1. 質量質量隨著每一次構件的重用，都會有一些錯誤被發現隨著每一次構件的重用，都會有一些錯誤被發現并被去除，構件的質量也會隨之

31、改善。隨著時間并被去除，構件的質量也會隨之改善。隨著時間的推移，構件將變本錢質上無錯誤的。的推移，構件將變本錢質上無錯誤的。2. 消費率消費率當把可重用的軟件成分運用于軟件開發的全過程當把可重用的軟件成分運用于軟件開發的全過程時，創建方案、模型、文檔、代碼和數據所需破時，創建方案、模型、文檔、代碼和數據所需破費的時間將減少，從而將用較少的投入給客戶提費的時間將減少，從而將用較少的投入給客戶提供一樣級別的產品，因此，消費率得到了提高。供一樣級別的產品，因此，消費率得到了提高。11.3.3 軟件重用的效益軟件重用的效益3. 本錢本錢軟件重用能節省的凈本錢軟件重用能節省的凈本錢C為：為： C=Cs-

32、Cr-CdCs是工程從頭開發沒有重用時所需求的本錢；是工程從頭開發沒有重用時所需求的本錢； Cd是交付給客戶的軟件的實踐本錢；是交付給客戶的軟件的實踐本錢；Cr是與重用相關聯的本錢，主要包括下述本錢：是與重用相關聯的本錢，主要包括下述本錢： 領域分析與建模的本錢；領域分析與建模的本錢； 設計領域體系構造的本錢；設計領域體系構造的本錢； 為便于重用而添加的文檔的本錢；為便于重用而添加的文檔的本錢； 維護和完善可重用的軟件成分的本錢；維護和完善可重用的軟件成分的本錢； 為從外部獲取構件所付出的版稅和答應證為從外部獲取構件所付出的版稅和答應證費；費； 創建或購買及運轉重用庫的費用；創建或購買及運轉重

33、用庫的費用； 對設計和實現可重用構件的人員的培訓費對設計和實現可重用構件的人員的培訓費用。用。在設計比較復雜的運用系統時普遍采用的戰略，是在設計比較復雜的運用系統時普遍采用的戰略，是首先把系統分解成假設干個比較小的部分，然后再首先把系統分解成假設干個比較小的部分，然后再分別設計每個部分。分別設計每個部分。系統的主要組成部分稱為子系統。通常根據所提供系統的主要組成部分稱為子系統。通常根據所提供的功能來劃分子系統。普通說來，子系統的數目應的功能來劃分子系統。普通說來，子系統的數目應該與系統規模根本匹配。該與系統規模根本匹配。各個子系統之間應該具有盡能夠簡單、明確的接口。各個子系統之間應該具有盡能夠

34、簡單、明確的接口。接口確定了交互方式和經過子系統邊境的信息流，接口確定了交互方式和經過子系統邊境的信息流，但是無須規定子系統內部的實現算法。因此，可以但是無須規定子系統內部的實現算法。因此，可以相對獨立地設計各個子系統。相對獨立地設計各個子系統。在劃分和設計子系統時，應該盡量減少子系統彼此在劃分和設計子系統時，應該盡量減少子系統彼此間的依賴性。間的依賴性。11.4 系統分解系統分解 面向對象設計模型面向對象設計模型(即求解域的對象模型即求解域的對象模型)，由下面，由下面5個層次組成：個層次組成： 主題主題 類與對象類與對象 構造構造 屬性屬性 效力效力這這5個層次一層比一層表示的細節更多，可以

35、把這個層次一層比一層表示的細節更多，可以把這5個層次想象為整個模型的程度切片。個層次想象為整個模型的程度切片。面向對象設計模型面向對象設計模型面向對象分析模型面向對象分析模型(即問題域的對象模型即問題域的對象模型)面向對象設計模型面向對象設計模型面向對象設計模型，在邏輯上都由面向對象設計模型，在邏輯上都由4大部分組成：大部分組成：人機交互部分人機交互部分問題域部分問題域部分義務管理部分義務管理部分數據管理部分數據管理部分這這4大部分對應于組成目的系統的大部分對應于組成目的系統的4個子系統：個子系統：問題域子系統問題域子系統人機交互子系統人機交互子系統義務管理子系統義務管理子系統數據管理子系統數

36、據管理子系統可以把面向對象設計模型的可以把面向對象設計模型的4大組成部分想象大組成部分想象成整個模型的成整個模型的4個垂直切片。個垂直切片。典型的面向對象設計模型可以用圖典型的面向對象設計模型可以用圖11.2表示。表示。圖圖11.2 典型的面向對象設計模型典型的面向對象設計模型1. 子系統之間的兩種交互方式子系統之間的兩種交互方式(1) 客戶客戶-供應商供應商(Client-supplier)關系關系在這種關系中，作為在這種關系中，作為“客戶的子系統調用作為客戶的子系統調用作為“供應商的子系統，后者完成某些效力任務并供應商的子系統，后者完成某些效力任務并前往結果。前往結果。 (2) 平等同伴平

37、等同伴(peer-to-peer)關系關系在這種關系中，每個子系統都能夠調用其他子系在這種關系中，每個子系統都能夠調用其他子系統，因此，每個子系統都必需了解其他子系統的統，因此，每個子系統都必需了解其他子系統的接口。接口。總的說來，單向交互比雙向交互更容易了解，也總的說來，單向交互比雙向交互更容易了解，也更容易設計和修正，因此應該盡量運用客戶更容易設計和修正，因此應該盡量運用客戶-供應供應商關系。商關系。2. 組織系統的兩種方案組織系統的兩種方案(1)程度層次組織程度層次組織 把軟件系統組織成一個層次系統，每層是一個子系把軟件系統組織成一個層次系統，每層是一個子系統。上層在下層的根底上建立，下

38、層為實現上層功能而統。上層在下層的根底上建立，下層為實現上層功能而提供必要的效力。每一層內所包含的對象，彼此間相互提供必要的效力。每一層內所包含的對象，彼此間相互獨立，而處于不同層次上的對象，彼此間往往有關聯。獨立，而處于不同層次上的對象，彼此間往往有關聯。實踐上，在上、下層之間存在客戶實踐上，在上、下層之間存在客戶-供應商關系。供應商關系。 層次構造又可進一步劃分成兩種方式：封鎖式和開層次構造又可進一步劃分成兩種方式：封鎖式和開放式。所謂封鎖式，就是每層子系統僅僅運用其直接下放式。所謂封鎖式，就是每層子系統僅僅運用其直接下層提供的效力。在開放方式中，某層子系統可以運用途層提供的效力。在開放方

39、式中，某層子系統可以運用途于其下面的任何一層子系統所提供的效力。于其下面的任何一層子系統所提供的效力。(2)垂直塊狀組織垂直塊狀組織這種組織方案把軟件系統垂直地分解成假設干個相對獨這種組織方案把軟件系統垂直地分解成假設干個相對獨立的、弱耦合的子系統，一個子系統相當于一塊，每塊立的、弱耦合的子系統，一個子系統相當于一塊，每塊提供一種類型的效力。提供一種類型的效力。利用層次和塊的各種能夠的組合，可以勝利地由多利用層次和塊的各種能夠的組合，可以勝利地由多個子系統組成一個完好的軟件系統。當混合運用層個子系統組成一個完好的軟件系統。當混合運用層次構造和塊狀構造時，同一層次可以由假設干塊組次構造和塊狀構造

40、時，同一層次可以由假設干塊組成，而同一塊也可以分為假設干層。成，而同一塊也可以分為假設干層。例如，圖例如，圖11.3表示一個運用系統的組織構造，這個表示一個運用系統的組織構造，這個運用系統采用了層次與塊狀的混合構造。運用系統采用了層次與塊狀的混合構造。圖圖11.3 典型運用系統的組織構造典型運用系統的組織構造3. 設計系統的拓撲構造設計系統的拓撲構造由子系統組成完好的系統時，典型的拓撲構造有：由子系統組成完好的系統時，典型的拓撲構造有： 管道形管道形 樹形樹形 星形星形設計者應該采用與問題構造相順應的、盡能夠簡單設計者應該采用與問題構造相順應的、盡能夠簡單的拓撲構造，以減少子系統之間的交互數量

41、。的拓撲構造，以減少子系統之間的交互數量。經過面向對象分析所得出的問題域準確模型，為設計問題經過面向對象分析所得出的問題域準確模型，為設計問題域子系統奠定了良好的根底，建立了完好的框架。只需能域子系統奠定了良好的根底，建立了完好的框架。只需能夠，就應該堅持面向對象分析所建立的問題域構造。通常，夠，就應該堅持面向對象分析所建立的問題域構造。通常，面向對象設計僅需從實現角度對問題域模型做一些補充或面向對象設計僅需從實現角度對問題域模型做一些補充或修正，主要是增添、合并或分解類與對象、屬性及效力，修正，主要是增添、合并或分解類與對象、屬性及效力，調整承繼關系等等。當問題域子系統過分復雜龐大時，應調整

42、承繼關系等等。當問題域子系統過分復雜龐大時，應該把它進一步分解成假設干個更小的子系統。該把它進一步分解成假設干個更小的子系統。運用面向對象方法學開發軟件，可以堅持問題域組織框架運用面向對象方法學開發軟件，可以堅持問題域組織框架的穩定性，從而便于追蹤分析、設計和編程的結果。在設的穩定性，從而便于追蹤分析、設計和編程的結果。在設計與實現過程中所做的細節修正計與實現過程中所做的細節修正(例如，添加詳細類，添加例如，添加詳細類，添加屬性或效力屬性或效力)，并不影響開發結果的穩定性，由于系統的總，并不影響開發結果的穩定性，由于系統的總體框架是基于問題域的。體框架是基于問題域的。11.5 設計問題域子系統

43、設計問題域子系統1. 調整需求調整需求有兩種情況：有兩種情況： 用戶需求或外部環境發生了變化；用戶需求或外部環境發生了變化； 面向對象分析模型不能完好、準確地反映用戶的真面向對象分析模型不能完好、準確地反映用戶的真實需求。實需求。方法是：簡單地修正面向對象分析結果，然后再把這方法是：簡單地修正面向對象分析結果，然后再把這些修正反映到問題域子系統中。些修正反映到問題域子系統中。2. 重用已有的類重用已有的類3. 把問題域類組合在一同把問題域類組合在一同在面向對象設計過程中，設計者往往經過引入一個根在面向對象設計過程中，設計者往往經過引入一個根類而把問題域類組合在一同。類而把問題域類組合在一同。在

44、面向對象設計過程中，能夠對面向對象分析所得在面向對象設計過程中，能夠對面向對象分析所得出的問題域模型做的補充或修正如下：出的問題域模型做的補充或修正如下：4. 增添普通化類以建立協議增添普通化類以建立協議在設計過程中，常有一些詳細類需求一個公共的協議，在設計過程中，常有一些詳細類需求一個公共的協議，即需求定義一組類似的效力。在這種情況下可以引入即需求定義一組類似的效力。在這種情況下可以引入一個附加類一個附加類(例如，根類例如，根類)，以便建立這個協議，以便建立這個協議(即命名即命名公共效力集合，這些效力在詳細類中仔細定義公共效力集合，這些效力在詳細類中仔細定義)。5. 調整承繼層次調整承繼層次

45、(1) 運用多重承繼機制運用多重承繼機制運用多重承繼機制時，應該防止出現屬性及效力的命運用多重承繼機制時，應該防止出現屬性及效力的命名沖突。下面經過例子闡明防止命名沖突的方法。名沖突。下面經過例子闡明防止命名沖突的方法。圖圖11.4 窄菱形方式窄菱形方式圖圖11.4是一種多重承繼方是一種多重承繼方式的例子，這種方式可以式的例子，這種方式可以稱為窄菱形方式。運用這稱為窄菱形方式。運用這種方式時出現屬性及效力種方式時出現屬性及效力命名沖突的能夠性比較大。命名沖突的能夠性比較大。圖圖11.5見書見書262頁是另頁是另一種多重承繼方式，稱為一種多重承繼方式，稱為闊菱形方式。運用這種方闊菱形方式。運用這

46、種方式時，屬性及效力的名字式時，屬性及效力的名字發生沖突的能夠性比較小，發生沖突的能夠性比較小，但是，它需求用更多的類但是，它需求用更多的類才干表示同一個設計。才干表示同一個設計。圖圖11.6 把多重承繼簡化為單一層次的單承繼把多重承繼簡化為單一層次的單承繼常見的做法是，把多常見的做法是，把多重承繼構造簡化成單重承繼構造簡化成單一的單承繼層次構造，一的單承繼層次構造，如圖如圖11.6所示。顯然，所示。顯然，在多重承繼構造中的在多重承繼構造中的某些承繼關系，經簡某些承繼關系，經簡化后將不再存在，這化后將不再存在，這闡明需求在各個詳細闡明需求在各個詳細類中反復定義某些屬類中反復定義某些屬性和效力。

47、性和效力。(2) 運用單承繼機制運用單承繼機制假設計劃運用僅提供單承繼機制的言語實現系統，假設計劃運用僅提供單承繼機制的言語實現系統，那么必需把面向對象分析模型中的多重承繼構造轉那么必需把面向對象分析模型中的多重承繼構造轉換成單承繼構造。換成單承繼構造。6. ATM系統實例系統實例圖圖11.7描畫了上章給出的描畫了上章給出的ATM系統的問題域子系統的構造。系統的問題域子系統的構造。在面向對象設計階段無須對已有的問題域模型作本質性的在面向對象設計階段無須對已有的問題域模型作本質性的修正或擴展。修正或擴展。圖圖11.7 ATM系統問題域子系統的構造系統問題域子系統的構造設計人機交互子系統的戰略：設

48、計人機交互子系統的戰略：1. 分類用戶分類用戶通常從以下幾個不同角度進展分類：通常從以下幾個不同角度進展分類：按技藝程度分類按技藝程度分類(新手、初級、中級、高級新手、初級、中級、高級)。按職務分類按職務分類(總經理、經理、職員總經理、經理、職員)。按所屬集團分類按所屬集團分類(職員、顧客職員、顧客)。11.6 設計人機交互子系統設計人機交互子系統2. 描畫用戶描畫用戶描畫用戶信息有：描畫用戶信息有：用戶類型。用戶類型。運用系統欲到達的目的。運用系統欲到達的目的。特征特征(年齡、性別、受教育程度、限制要素等年齡、性別、受教育程度、限制要素等)。關鍵的勝利要素關鍵的勝利要素(需求、喜好、習慣等需

49、求、喜好、習慣等)。技藝程度。技藝程度。完本錢職任務的腳本。完本錢職任務的腳本。3. 設計命令層次設計命令層次(1) 研討現有的人機交互含義和準那么研討現有的人機交互含義和準那么(2) 確定初始的命令層次確定初始的命令層次所謂命令層次，本質上是用過程籠統機制組織起來的、所謂命令層次，本質上是用過程籠統機制組織起來的、可供選用的效力的表示方式。可供選用的效力的表示方式。設計命令層次時，通常先從對效力的過程籠統著手，設計命令層次時，通常先從對效力的過程籠統著手，然后再進一步修正它們，以適宜詳細運用環境的需求。然后再進一步修正它們，以適宜詳細運用環境的需求。(3) 精化命令層次精化命令層次應該思索以

50、下一些要素：應該思索以下一些要素：次序：仔細選擇每個效力的名字，并在命令層的每一次序：仔細選擇每個效力的名字，并在命令層的每一部分內把效力排好次序。部分內把效力排好次序。整體整體-部分關系：尋覓在這些效力中存在的整體部分關系：尋覓在這些效力中存在的整體-部分方部分方式，這樣做有助于在命令層中分組組織效力。式，這樣做有助于在命令層中分組組織效力。寬度和深度：命令層次的寬度和深度都不應該過大。寬度和深度：命令層次的寬度和深度都不應該過大。操作步驟：應該用盡量少的單擊、拖動和擊鍵組合來操作步驟：應該用盡量少的單擊、拖動和擊鍵組合來表達命令，而且應該為高級用戶提供簡捷的操作方法。表達命令，而且應該為高

51、級用戶提供簡捷的操作方法。4. 設計人機交互類設計人機交互類人機交互類與所運用的操作系統及編程言語親密相關。人機交互類與所運用的操作系統及編程言語親密相關。例如，在例如，在Windows環境下運轉的環境下運轉的Visual C+言語提供言語提供了了MFC類庫，設計人機交互類時，往往僅需從類庫，設計人機交互類時，往往僅需從MFC類庫中選出一些適用的類，然后從這些類派生出符合類庫中選出一些適用的類，然后從這些類派生出符合本人需求的類就可以了。本人需求的類就可以了。設計任務的一項重要內容就是，確定哪些是必需同時動作設計任務的一項重要內容就是，確定哪些是必需同時動作的對象，哪些是相互排斥的對象。然后進

52、一步設計義務管的對象，哪些是相互排斥的對象。然后進一步設計義務管理子系統。理子系統。11.7 設計義務管理子系統設計義務管理子系統1. 分析并發性分析并發性經過面向對象分析建立起來的動態模型，是分析并發性的經過面向對象分析建立起來的動態模型，是分析并發性的主要根據。假設兩個對象彼此間不存在交互，或者它們同主要根據。假設兩個對象彼此間不存在交互，或者它們同時接受事件，那么這兩個對象在本質上是并發的。時接受事件，那么這兩個對象在本質上是并發的。經過檢查各個對象的形狀圖及它們之間交換的事件，可以經過檢查各個對象的形狀圖及它們之間交換的事件，可以把假設干個非并發的對象歸并到一條控制線中。所謂控制把假設

53、干個非并發的對象歸并到一條控制線中。所謂控制線，是一條普及形狀圖集合的途徑，在這條途徑上每次只線，是一條普及形狀圖集合的途徑，在這條途徑上每次只需一個對象是活動的。在計算機系統中用義務需一個對象是活動的。在計算機系統中用義務(task)實現控實現控制線，普通以為義務是進程制線，普通以為義務是進程(process)的別名。通常把多個義的別名。通常把多個義務的并發執行稱為多義務。務的并發執行稱為多義務。對于某些運用系統來說，經過劃分義務，可以簡化系統的對于某些運用系統來說，經過劃分義務，可以簡化系統的設計及編碼任務。不同的義務標識了必需同時發生的不同設計及編碼任務。不同的義務標識了必需同時發生的不

54、同行為。這種并發行為既可以在不同的處置器上實現，也可行為。這種并發行為既可以在不同的處置器上實現，也可以在單個處置器上利用多義務操作系統仿真實現以在單個處置器上利用多義務操作系統仿真實現(通常采用通常采用時間分片戰略仿真多處置器環境時間分片戰略仿真多處置器環境)。2. 設計義務管理子系統設計義務管理子系統常見的義務有事件驅動型義務、時鐘驅動型義務、優先義常見的義務有事件驅動型義務、時鐘驅動型義務、優先義務、關鍵義務和協調義務等。設計義務管理子系統，包括務、關鍵義務和協調義務等。設計義務管理子系統，包括確定各類義務并把義務分配給適當的硬件或軟件去執行。確定各類義務并把義務分配給適當的硬件或軟件去

55、執行。1 確定事件驅動型義務確定事件驅動型義務某些義務是由事件驅動的，這類義務能夠主要完成通訊任某些義務是由事件驅動的，這類義務能夠主要完成通訊任務。例如，與設備、屏幕窗口、其他義務、子系統、另一務。例如，與設備、屏幕窗口、其他義務、子系統、另一個處置器或其他系統通訊。事件通常是闡明某些數據到達個處置器或其他系統通訊。事件通常是闡明某些數據到達的信號。的信號。在系統運轉時，這類義務的任務過程如下：義務處于睡眠在系統運轉時，這類義務的任務過程如下：義務處于睡眠形狀形狀(不耗費處置器時間不耗費處置器時間)，等待來自數據線或其他數據源的，等待來自數據線或其他數據源的中斷；一旦接納到中斷就喚醒了該義務

56、，接納數據并把數中斷；一旦接納到中斷就喚醒了該義務，接納數據并把數據放入內存緩沖區或其他目的地，通知需求知道這件事的據放入內存緩沖區或其他目的地，通知需求知道這件事的對象，然后該義務又回到睡眠形狀。對象，然后該義務又回到睡眠形狀。2 確定時鐘驅動型義務確定時鐘驅動型義務某些義務每隔一定時間間隔就被觸發以執行某些處置。在某些義務每隔一定時間間隔就被觸發以執行某些處置。在這些場所往往需求運用時鐘驅動型義務。這些場所往往需求運用時鐘驅動型義務。時鐘驅動型義務的任務過程如下：義務設置了喚醒時間后時鐘驅動型義務的任務過程如下：義務設置了喚醒時間后進入睡眠形狀；義務睡眠進入睡眠形狀；義務睡眠(不耗費處置器

57、時間不耗費處置器時間)，等待來自，等待來自系統的中斷；一旦接納到這種中斷，義務就被喚醒并做它系統的中斷；一旦接納到這種中斷，義務就被喚醒并做它的任務，通知有關的對象，然后該義務又回到睡眠形狀。的任務，通知有關的對象，然后該義務又回到睡眠形狀。3 確定優先義務確定優先義務優先義務可以滿足高優先級或低優先級的處置需求：優先義務可以滿足高優先級或低優先級的處置需求：高優先級：某些效力具有很高的優先級，為了在嚴厲限定高優先級：某些效力具有很高的優先級，為了在嚴厲限定的時間內完成這種效力，能夠需求把這類效力分別成獨立的時間內完成這種效力，能夠需求把這類效力分別成獨立的義務。的義務。低優先級：與高優先級相

58、反，有些效力是低優先級的，屬低優先級：與高優先級相反，有些效力是低優先級的，屬于低優先級處置于低優先級處置(通常指那些背景處置通常指那些背景處置)。設計時能夠用額。設計時能夠用額外的義務把這樣的處置分別出來。外的義務把這樣的處置分別出來。4 確定關鍵義務確定關鍵義務關鍵義務是有關系統勝利或失敗的關鍵處置，這類處關鍵義務是有關系統勝利或失敗的關鍵處置，這類處置通常都有嚴厲的可靠性要求。置通常都有嚴厲的可靠性要求。在設計過程中能夠用額外的義務把這樣的關鍵處置分在設計過程中能夠用額外的義務把這樣的關鍵處置分別出來，以滿足高可靠性處置的要求。對高可靠性處別出來，以滿足高可靠性處置的要求。對高可靠性處置

59、應該精心設計和編碼，并且應該嚴厲測試。置應該精心設計和編碼，并且應該嚴厲測試。5 確定協調義務確定協調義務當系統中存在當系統中存在3個以上義務時，就應該添加一個義務，個以上義務時，就應該添加一個義務，用它作為協調義務。用它作為協調義務。引入協調義務會添加系統的總開銷引入協調義務會添加系統的總開銷(添加從一個義務到添加從一個義務到另一個義務的轉換時間另一個義務的轉換時間)，但是引入協調義務有助于把，但是引入協調義務有助于把不同義務之間的協調控制封裝起來。運用形狀轉換矩不同義務之間的協調控制封裝起來。運用形狀轉換矩陣可以比較方便地描畫該義務的行為。這類義務應該陣可以比較方便地描畫該義務的行為。這類

60、義務應該僅做協調任務，不要讓它再承當其他效力任務。僅做協調任務，不要讓它再承當其他效力任務。6 盡量減少義務數盡量減少義務數必需仔細分析和選擇每個確實需求的義務。應該使系必需仔細分析和選擇每個確實需求的義務。應該使系統中包含的義務數盡量少。統中包含的義務數盡量少。7 確定資源需求確定資源需求設計者在決議究竟采用軟件還是硬件的時候，必需綜設計者在決議究竟采用軟件還是硬件的時候，必需綜合權衡一致性、本錢、性能等多種要素，還要思索未合權衡一致性、本錢、性能等多種要素，還要思索未來的可擴展性和可修正性。來的可擴展性和可修正性。運用多處置器或固件，主要是為了滿足高性能的需求。運用多處置器或固件，主要是為