1、1第7章 面向對象的設計 2軟件設計設計設計是研究系統的軟件實現問題，即在分析模型的基礎上形成實現環境下的設計模型。面向對象設計面向對象設計是根據已建立的系統分析模型，運用面向對象技術，進行系統的軟件設計。通常包括系統設計和詳細設計（或組件設計）兩個層次3面向對象設計系統設計選擇合適的解決方案策略，并將系統劃分為若干子系統，從而建立整個系統的體系結構詳細設計細化原有的分析對象，確定一些新對象，對每個子系統接口和類進行準確詳細的說明4面向對象設計面向對象設計的制品設計類考慮與實現有關的因素，具體描述操作的參數、屬性和類型等。類的設計應當充分利用預定義的系統類庫或其他來源的現有類， 并采用繼承、復

2、用、演化等方法設計所需要的新類。用例實現（ 從設計角度 ）基于用例實現的分析結果，使用設計類及其對象描述一個用例是如何實現和執行的。通常由類圖、交互圖、事件流設計（即使用對象或子系統的術語進行文本描述）和與實現相關的需求組成。5面向對象設計面向對象設計的制品（續）設計子系統與接口子系統是組織設計模型的一種手段，用以描述大粒度的構件，通常由設計類、用例實現、接口和其它子系統等組成。接口表示由設計類和子系統提供的操作。體系結構描述（ 從設計角度 ）從設計模型的角度，描述系統的體系結構；通常包括由設計模型分解的子系統、接口、依賴、關鍵設計類和 用例實現的設計。6面向對象設計面向對象設計的制品（續）部

3、署圖根據系統在計算節點上的功能分布，描述整體的物理分布。7面向對象設計的過程8系統設計設計系統的體系結構選擇合適的體系結構策略，建立系統的總體結構識別設計元素(7.2.1)識別類和子系統識別子系統接口定義數據的存儲策略部署子系統選擇硬件配置和系統平臺，將子系統分配到相應的物理節點檢查系統設計9MiniLibrary：軟件體系結構10系統設計設計系統的體系結構選擇合適的體系結構策略，建立系統的總體結構識別設計元素識別類和子系統識別子系統接口定義數據的存儲策略部署子系統選擇硬件配置和系統平臺，將子系統分配到相應的物理節點檢查系統設計11識別設計元素127.2.1識別設計類設計類由面向對象分析模型中

4、的分析類得到。對于邊界類的設計依賴于所采用的特定的接口技術。接口技術不同，設計類不同。實體類用于表示持久信息，因此實體類的設計和特定的數據存儲或數據庫技術相關。例如，創建用來映射到關系數據模型中的數據表的設計類。137.2.1識別設計類控制類的設計較為復雜，它們封裝了控制邏輯、與其它對象的協作以及業務邏輯問題。因此主要需要考慮以下問題：（1）分布問題：如果控制需要被分布到網絡中的幾個不同節點當中加以管理，那么在這些節點上需要單獨的設計類來實現控制。（2）性能問題：在各個節點上使用單獨的設計類來實現控制類并不一定合理，可以由一些相關的邊界類或實體類的設計類來實現控制類。（3）事務問題：控制類通常

5、封裝事務，相應的設計也必須體現事務的管理。147.2.1識別設計類確定設計元素的基本原則如果一個“分析類”比較簡單，代表著單一的邏輯抽象，那么可 以將其映射為“設計類”。通常，主動參與者對應的邊界類、控 制類和一般的實體類都可以直接映射成設計類。如果“分析類”的職責比較復雜，很難由單個“設計類”承擔，則 應該將其映射成“子系統接口”或“子系統”。通常，被動參與者對應的邊界類被映射成子系統接口。子系統的劃分應該符合高內聚低耦合的原則。問題：MiniLibrary 系統的分析類哪些應該直接映射成設計類？哪 些應該映射成子系統？15MiniLibrary：識別邊界類16MiniLibrary：識別控

6、制類17MiniLibrary：識別實體類18面向對象設計的過程19詳細設計詳細設計的主要任務（補充）精化設計類 明確定義操作的參數和基本的實現邏輯（方法建模;7.2.2）明確定義屬性的類型和可見性（屬性建模;7.2.3）明確類的狀態（狀態建模）明確類之間的關系（關系建模;7.2.4）明確類之間的交互（設計交互;7.3）整理和優化設計模型207.2.2識別類的方法確定了設計類后，需要定義設計類提供的方法，方法定義主要基于：（1）分析類的職責。每個職責通常暗含一個或多個方法。此外，如果分析模型中為職責描述了輸入和輸出，那么這些輸入和輸出可以用作形參和方法結果值的初步定義。一般，設計類的方法可由分

7、析類得到。217.2.2識別類的方法確定了設計類后，需要定義設計類提供的方法。方法定義主要基于：（2）分析類的特殊需求。一個設計類的方法需要支持該類在不同的用例實現中所扮演的所有角色。遍歷用例實現，并查看類和它的對象是否包含在該用例實現圖中和實現的事件流描述中從而可發現這些角色，并獲得該設計類的方法。當分析類對象的行為由狀態控制，即當它們接收到一個消息時，其狀態決定了它們的行為。由狀態圖的消息可輕易識別分析類的方法22狀態建模在詳細設計階段，狀態建模一般只發生在依賴狀態展示不同行為的類上。對分析類的狀態建模可進一步識別設計類的方法237.2.2識別類的方法確定了設計類后，需要定義設計類提供的方

8、法。方法定義主要基于：（3）設計類需要提供的接口。接口的方法也需要由設計類提供。24定義類的方法總的說來，定義設計類方法的過程找出滿足基本邏輯要求的操作補充必要的輔助操作初始化類的實例驗證兩個實例是否等同完整地描述操作確定操作的名稱、參數、返回值、可見性等應該遵從程序設計語言的命名規則簡要說明操作的內部實現邏輯25定義類的操作（方法建模）舉例：BorrowerInfo 類構造函數 + new ( )屬性賦值+ setName ( name:String )+ setAddress ( address:String )其他+ addLoan ( theLoan:Loan )+ removeLoa

9、n ( theLoan:Loan )+ isAllowed ( ) : Boolean26詳細設計詳細設計的主要任務（補充）精化設計類 明確定義操作的參數和基本的實現邏輯（方法建模;7.2.2）明確定義屬性的類型和可見性（屬性建模;7.2.3）明確類的狀態（狀態建模）明確類之間的關系（關系建模;7.2.4）明確類之間的交互（設計交互;7.3）整理和優化設計模型277.2.3識別屬性設計類的屬性可繼承自分析類識別屬性時應基于以下的原則：（1）設計類所關聯的分析類的屬性。有時，分析類的屬性隱含著設計類需要的一個或多個屬性；（2）對可用的屬性類型加約束標記，如private；（3）當選擇一個屬性類型

10、時，盡可能重用已經存在的屬性類型；（4）一個類的屬性不能被多個設計對象共享。如果需要共享，就需要將該屬性定義成一個單獨的類；（5）如果一個設計類因為其屬性的原因變得復雜而難于理解，那么其中的一些屬性可以分離出來變成它們自己的類；（6）如果一個類存在大量的或者復雜的屬性，可以在一個單獨呈現屬性部分的類圖中進行描述。28定義屬性（屬性建模）總之，定義屬性具體說明屬性的名稱、類型、缺省值、可見性等基本原則將所有屬性的可見性設置為 private；僅通過 set 方法更新屬性；僅通過 get 方法訪問屬性；在屬性的 set 方法中，實現簡單的有效性驗證，而在獨立的驗證方法中實現復雜的邏輯驗證。29精化

11、后的Borrowinfo類30詳細設計詳細設計的主要任務（補充）精化設計類 明確定義操作的參數和基本的實現邏輯（方法建模;7.2.2）明確定義屬性的類型和可見性（屬性建模;7.2.3）明確類的狀態（狀態建模）明確類之間的關系（關系建模;7.2.4）明確類之間的交互（設計交互;7.3）整理和優化設計模型317.2.4識別關聯和聚合設計類的關聯和聚合可來源于它們繼承的分析類的關聯和聚合原則：（1）考察相應的分析類中的關聯和聚合。這些關系通常隱含著設計類需要的一個或多個相應的關系；（2）精化關聯多重性、角色名稱、關聯類、n元關聯。當編碼實現時，角色名稱有時可以轉變成設計類的屬性，從而限定角色在“關聯

12、”類和發生關聯的兩個類之間有一個具有合適多重性的新關聯；（3）精化關聯的導航性。類之間關聯的相應導航性可用以定義對象之間的消息傳送方向。32例如：識別關聯關系時獲得關聯類有些情況下，關聯關系本身也可能具有屬性，可以使 用“關聯類”將這種關系建模。舉例：選課表 Schedule 與開設課程 CourseOffering337.2.4識別關聯和聚合3435詳細設計詳細設計的主要任務（補充）精化設計類 明確定義操作的參數和基本的實現邏輯（方法建模;7.2.2）明確定義屬性的類型和可見性（屬性建模;7.2.3）明確類的狀態（狀態建模）明確類之間的關系（關系建模;7.2.4）明確類之間的交互（設計交互;

13、7.3）整理和優化設計模型367.3設計交互當確定了設計類及類的詳細定義，應對設計對象間的交互行為進行描述和建模。 在設計過程中，通常采用順序圖來建模用例實現。377.3設計交互創建順序圖時應該注意：（1）用例由從參與者實例到設計對象傳遞的消息所開始。（2）對于識別出的每個設計類，應該至少有一個設計對象參與到某個順序圖中。（3）消息在對象生命線間傳遞以便實現用例。一個消息應被命名，這個名稱也是對象操作的名稱。（4）應重點關注圖中消息傳送在時間上的先后順序。（5）利用事件流描述來補充順序圖。（6）順序圖應該建模所實現的用例的所有交互。在順序圖中可能包含子系統，這是需要對子系統接口進行描述。387

14、.3設計交互397.6 用戶界面設計是軟件系統能否成功的關鍵。通常單獨設計 40用戶界面的設計原則用戶控制式用戶啟動行為并取得結果，如果程序取得控制權的話，用戶也要獲得必要的反饋（一個沙漏、一個等待的指示器或其他 類似的東西）。一致性遵循標準和常規的方式，應該讓用戶處在一個熟悉的和可預見的環境之中。若應用是為 Windows 開發的，則應采用 Windows “外觀和感覺”；菜單、活動按鈕、屏幕區域等的命名和編碼、對象在屏幕上處于 什么位置的標準等的一致性也不能低估。41用戶界面的設計原則個性化個性化可以使不同的人按照自己的習慣和愛好設置用戶界面元素，例如用戶可以自己設置和排列系統的操作菜單。

15、寬容性一個好的界面應該以一種寬容的態度允許用戶進行實驗和出錯，用戶在出現錯誤時能夠方便地從錯誤中恢復。反饋在錯誤發生或程序運行時間較長時，界面應該提供有意義的反饋，并有上下文感知的幫助功能。42用戶界面的設計原則審美和可用性審美是視覺上的吸引力；可用性是用戶使用過程中的方便性、簡單性、有效性、可靠 性和快捷性等。43Web 界面設計原則簡潔性避免使用許多復雜的圖片和動畫等造成用戶操作的分心界面布局應當適合清晰地表達信息具有與之匹配的導航性一致性諸如同樣的按鈕在所有窗口中保持一致的位置、始終使用一 致的配色方案等強調美學不能取代功能（ Functionality Aesthetics ）44We

16、b 界面的美觀與性能在 Web 界面設計時，需要注意美觀和性能之間的折中平衡，太大的圖片會造成系統時間的不必要浪費。 45Web 界面布局46Web 界面布局47固定寬度 vs. 可變寬度48界面中的顏色顏色能夠改善用戶界面，幫助用戶理解系統的復雜信 息結構，有時顏色可以用于突出顯示例外事件。使用顏色的指導原則避免使用太多的顏色（通常一個窗口內不要多于三種顏色）使用顏色編碼支持用戶的任務允許用戶控制顏色編碼使用顏色編碼時需要前后一致使用顏色的變化顯示系統狀態的變化注意在低分辨率情況下的顏色顯示注意顏色的搭配49界面中的顏色50動態變化的信息窗口51面向對象設計的過程52應用設計模式（9.3 P

17、146）面向復用的軟件在設計時需要考慮應用設計模式。復用分為三類形式，類復用，組件復用和概念復用 所謂概念復用是指對已有的軟件方法、模式，體系結構復用 設計模式描述了系統設計過程中常見問題的解決方案， 它是從大量的成功實踐中總結出來的。設計模式重用了有經驗人員的設計模式 = 文檔化的經驗53經典的設計模式54經典的設計模式559.3.1 Composite模式Composite模式沿用繼承機制組合設計類。又稱做部分-整體模式將設計類對象以樹形結構組織起來，以達成“部分（單個對象）整體（組合對象）” 的層次結構。它使我們樹型結構的問題中，模糊了單個對象和組合對象的概念，客戶程序可以像處理單個對象

18、一樣來處理組合對象使得客戶端對單個對象和組合對象的使用具有一致性569.3.1 Composite模式Composite模式適用于以下兩種情況：（1）表示對象的整體-部分層次結構；（2）希望可以忽略組合對象和單個對象的不同。579.3.1 Composite模式例如對于一個圖形編輯器程序一個較復雜的圖形可以由若干個基本的圖形組合而成這些圖形又可組合成更大、更復雜的圖形。對于該程序中圖形類的設計一種簡單的實現方法是分別定義基本的圖形和組合圖形為圖元類和容器類，但引用這些對象的代碼將會區別對待。589.3.1 Composite模式可復用Composite模式進行設計，避免上述缺陷定義一個抽象類G

19、raphic，如圖9.7所示，它既可以代表圖元類也可以表示容器類Graphic類定義了圖元類和容器類一般都具有的通用操作接口Draw()、Add()、Remove()等，也定義了容器類特有的操作GetChild()。Graphic的子類Line、Rectangle、Text是具體實現圖元的類，而Picture子類則定義了一個組合圖形類的具體實現，它是圖元類對象的聚合。Picture的接口和Graphic的接口是一致的，從圖中可以看出Picture對象可以遞歸組合其他Picture對象。599.3.1 Composite模式Composite模式的結構如圖9.9所示 609.3.1 Compos

20、ite模式：例子例如：一個GUI系統的窗口對象既可以包含按鈕、文本框、復選框等各類GUI組件，也可以包含Widget容器，Widget容器包含其他的Widget組件。如果需要刷新窗口，那么對于不同的Widget組件，如何來設計刷新方法呢？例如：為Java程序提供圖形用戶接口的Java的圖形和用戶界面器件工具包AWT即采用了Composite模式思想。 619.3.2 Abstract Factory模式Abstract Factory 模式該模式適用于封裝具體平臺，使應用可在不同平臺上運行。特點：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類 Abstract Factor

21、y模式的結構如圖9.13所示 62抽象工廠模式設計的數據訪問層639.3.2 Abstract Factory模式如果需要設計出一個可支持多種所見即所得（lookand-feel）標準的用戶界面工具包如Motif標準和Presentation標準。不同的標準使得用戶界面在滾動條、窗口、按鈕等界面組件呈現不同的風格。在設計和實現中不應直接對一個界面組件類硬性指定其風格，這樣在實例化處理中很難改變風格。649.3.2 Abstract Factory模式可以定義一個抽象的WidgetFactory類，如圖9.12所示。抽象類WidgetFactory定義了創建窗口組件對象的方法CreatScrol

22、lBar()、CreateWindow()，但對象的實際創建（實例化）則是其實現子類MotifWidgetFactory或PMWidgetFactory的CreatScrollBar()、CreateWindow()方法來實現的，它們分別創建兩類不同風格的窗口組件對象，而應用程序（Client）僅需調用WidgetFactory的方法CreatScrollBar()、CreateWindow()以獲得窗口組件對象，卻不必知道究竟使用的是哪一個具體的類，使窗口組件對象的使用者（Client）不依賴于特定的窗口風格。即客戶僅與抽象類的接口打交道，而不使用具體實現類的接口 每一種標準窗口組件都有一個

23、抽象類，而這種標準風格的窗口組件的具體實現則是由具體的實現子類來定義 65Adaptor 模式Adaptor 模式該模式的目的是封裝遺留系統的代碼。6667Bridge 模式Bridge 模式該模式將一個類的接口與具體實現進行分離。68Bridge 模式假如需要開發一個同時支持PC和手機的坦克游戲，游戲在PC和手機上功能都一樣，都有同樣的類型，面臨同樣的功能需求變化，比如坦克可能有多種不同的型號：T50,T75, T90對于其中的坦克設計，我們可能很容易設計出來一個Tank的抽象基類（接口），然后各種不同型號的Tank繼承自該類：/ 抽象部分（接口）public abstract class

24、Tank public abstract Shot();public abstract Run();public abstract Trun();/各種實現public class T50: Tank public class T75: Tank public class T90: Tank 69Bridge 模式但是PC和手機上的圖形繪制、聲效、操作等實現完全不同.因此對于各種型號的坦克，都要提供各種不同平臺上的坦克實現：/PC平臺實現public class PCT50:T50 public class PCT75: T75 public class PCT90: T90 /手機平臺實現public class MobileT50: T50 public class MobileT75: T75 public class MobileT90: T90 只有一個抽象類（接口）