面向對象設計本章概述2本章首先介紹面向對象設計與結構化設計的不同點，以及面向對象設計與面向對象分析的關系。然后介紹面向對象設計的過程、原則和啟發規則。接著講述系統設計，包括系統分解以及對問題域子系統、人機交互子系統、任務管理子系統、和數據管理子系統的設計。最后，對對象設計進行較為詳細的闡述，包括設計類中的服務、設計類的關聯和對象設計優化。本章目標：了解面向對象設計與結構化設計的不同理解面向對象設計與面向對象分析的關系理解面向對象設計的過程、原則和啟發規則熟悉面向對象系統分解方法熟悉面向對象問題域、人機交互、任務管理和數據管理各子系統的設計方法掌握對象設計方法目錄39.1面向對象設計與結構化設計9.2面向對象設計與面向對象分析的關系9.3面向對象設計的過程與規則9.4面向對象設計的啟發規則9.5系統設計9.6對象設計第一節面向對象設計與結構化設計9.1面向對象設計與結構化設計與結構化的設計相比，面向對象的設計更符合復雜的、隨機性較強和考慮并發性的系統軟件設計，而不適合邏輯性很強的系統軟件設計。結構化軟件設計一般從系統功能入手，按照需求將系統功能分為若干個子功能模塊。但是，用戶的需求是在不斷變化的。需求的改變往往會對功能模塊產生影響，從而對整個系統產生影響，而面向對象的設計基于類、對象、封裝、繼承等概念，相比之下，需求的變化對系統的局部影響并不容易擴展到全局。因此，面向對象設計方法比結構化設計方法更具有優勢，使用范圍更廣。59.1面向對象設計與結構化設計由于在類中封裝了屬性和方法，因此在面向對象的類設計中已經包含了面向過程中的過程設計。此外，與面向過程中的數據設計所不同的是，面向對象設計中的數據設計并不是獨立進行的，面向對象設計中的類圖相當于數據的邏輯模型，可以很容易地轉換成數據的物理模型。6第二節面向對象設計與面向對象分析的關系9.2面向對象設計與面向對象分析的關系設計階段的任務是及時把分析階段得到的需求轉變成符合各項要求的系統實現方案。與傳統的軟件工程方法不同的是，面向對象的方法不強調需求分析和軟件設計的嚴格區分。實際上，面向對象的需求分析和面向對象的設計活動是一個反復迭代的過程，從分析到設計的過渡，是一個逐漸擴充、細化和完善分析階段所得到的各種模型的過程。嚴格的意義上來講，從面向對象分析到面向對象設計不存在轉換問題，而是同一種表示方法在不同范圍的運用。面向對象設計也不僅僅是對面向對象分析模型進行細化。89.2面向對象設計與面向對象分析的關系面向對象分析到面向對象設計是一個平滑的過渡，即沒有間斷沒有明確的分界線。面向對象分析建立系統的問題域對象模型，而面向對象設計是建立求解域的對象模型。都是建模過程，但二者性質有別。分析建模可以脫離系統的具體實現，而設計建模需要考慮系統的具體實現環境的約束，例如選用語言，開發人員等問題。9第三節面向對象設計的過程與規則9.3.1面向對象設計的過程（1）建立軟件體系結構環境圖

在軟件體系結構設計開始的時候，設計應該定義與軟件進行交互的外部實體（其他系統、設備和人員等）以及交互的特性。一般在分析建模階段可以獲得這些信息，并使用軟件體系結構環境圖對環境進行建模，描述系統的出人信息流、用戶界面和相關的支持處理。一旦建立了軟件體系結構的環境圖，描述出所有的外部軟件接口，軟件架構師就可以通過定義和求精實現軟件體系結構的構件來描述系統的結構。這個過程可一直迭代，直到獲得一個完善的軟件體系結構。在設計的初始階段，軟件架構師用軟件體系結構環境圖對軟件與外部實體交互的方式進行建模。119.3.1面向對象設計的過程12如圖所示，與目標系統（即開發軟件體系結構的系統）交互的系統可以表示為：上級系統：將目標系統作為某些高層處理方案的一部分。下級系統：被目標系統所使用，并且為完成目標系統的功能提供必要的數據和處理同級系統：在對等的基礎上相互作用（例如，信息要么由目標系統和同級系統產生，要么被目標系統和同級系統使用）。參與者：指通過產生和使用所需的信息，實現與目標系統交互的實體（人、設備)。每個外部實體都通過某一接口（帶陰影的小矩形）與目標系統進行通信。9.3.1面向對象設計的過程（2）軟件體系結構設計

軟件體系結構環境圖建立之后，而且對所有的外部軟件接口進行了描述，就可以進行軟件體系結構設計了。軟件體系結構設計可以自底向上進行，先為系統中最底層細節編程，然后逐步在更高層累計細節直至最終滿足系統需求，如將關系緊密的對象組織成子系統或層；也可以自頂向下進行，通過分解功能來解決問題，尤其是使用設計模式或遺產系統時，會從子系統的劃分人手；還可以自中向上下進行，先開始做系統中看來容易做的，再向相應的高層或底層擴展。至于選擇哪一種方式，需要根據具體的情況來確定。當沒有類似的軟件體系結構作為參考時，常常會使用自底向上的方式進行軟件體系結構設計。多數情況下，使用自頂向下的方式進行軟件體系結構設計則更常見。139.3.1面向對象設計的過程（2）軟件體系結構設計在自頂向下這種方式下，首先要根據客戶的需求選擇軟件體系結構風格，然后對可選的軟件體系結構風格或模式進行分析，以建立最適合客戶需求和質量屬性的結構。需要強調的是，軟件體系結構設計這個過程可一直迭代，直到獲得一個完善的軟件體系結構。有經驗的軟件設計人員應能按照項目所需的策略進行軟件體系結構設計。149.3.1面向對象設計的過程（3）對各個子系統進行設計

大多數系統的面向對象設計模型，在邏輯上都由4大部分組成。這4大部分對應于組成目標系統的4個子系統，它們分別是：問題域子系統人—機交互子系統任務管理子系統數據管理子系統當然，在不同的軟件系統中，這4個子系統的重要程度和規模可能相差很大，規模過大的在設計過程中應該進一步劃分成更小的子系統，規模過小的可合并在其他子系統中。某些領域的應用系統在邏輯上可能僅由3個（甚至少于3個）子系統組成。159.3.1面向對象設計的過程（4）對象設計及優化

對象設計是細化原有的分析對象，確定一些新的對象、對每一個子系統接口和類進行準確詳細的說明。系統的各項質量指標并不是同等重要的，設計人員必須確定各項質量指標的相對重要性（即確定優先級），以便在優化對象設計時制定折衷方案。常見的對象優化設計方法有提高效率的技術和建立良好的繼承結構。169.3.2面向對象設計的原則

面向對象的設計原則基本遵循傳統軟件設計應該遵循的基本原理，同時還要考慮面向對象的特點。設計原則具體如下。模塊化：結構化設計中，一個模塊通常為一個過程或一個函數，它們封裝了一系列控制邏輯。而面向對象設計中，一個模塊通常為一個類或對象，封裝了事物屬性和行為。抽象化：類是對一組具有相似特征的對象的抽象，而對象是對客觀事物的抽象。信息隱藏：對于類而言，其內部信息如屬性的表示方法和操作的實現算法，對外界是隱藏的。外界通過有限的接口來訪問類的內部信息。179.3.2面向對象設計的原則低耦合：在面向對象設計中，耦合主要指對象之間相互關聯的緊密程度，低耦合有利于降低一個模塊改變對其他模塊的影響。高內聚：內聚與耦合密切相關，低耦合往往意味著高內聚，高內聚有助于提高系統獨立性。復用性：盡量使用已有的類；構造新類時，需要考慮該類將來被復用的可能。提高類的復用性以節約資源。189.4面向對象設計的啟發規則面向對象設計的啟發規則是人們在長期的基于面向對象思想的軟件開發實踐中總結出來的經驗，有利于提高開發人員進行軟件設計的質量。啟發規則具體如下。設計結果應該清晰易懂：可以為后續的軟件開發提供便利，同時還能夠提高軟件可維護性。要做到這一點首先應該注意對類、屬性、操作的命名，確保含義清晰一致。其次開發過程中設計新類時應盡量遵循已有的協議，遵守消息模式（如果已經定義）。類等級深度應該適當：不能隨意創建派生類，對于中等規模系統，類的等級層數應在5-9。要盡量設計簡單的類：便于開發和管理。過于龐大的類會造成維護困難、不靈活等問題。應盡量簡化對象之間的合作關系，為每個類分配的任務盡量簡單，控制類中包含的屬性和操作的數量。199.4面向對象設計的啟發規則使用簡單的協議：減少消息的參數個數時降低類之間耦合程度的有效手段。一般來說參數最好在3個以內，且數據類型應該盡量簡單。使用簡單的操作：控制操作中源程序的語句行數或語句嵌套層數，從而簡化操作。把設計的變動減至最小：設計的變動會造成資源或時間上的消耗。雖然變動是正常情況，但開發人員設計時應盡量降低變動的概率。209.5系統設計21系統設計關注于確定實現系統的策略和目標系統的高層結構。設計人員將問題分解為若干個子系統，子系統之間通過接口聯系。將系統分解為子系統要按照一定的拓撲關系。問題域指與應用問題直接相關的類或對象。在面向對象需求分析時已經定義了類與對象及其關系。但隨著需求理解的加深，以及對系統認識程度的逐步提高，設計人員還要對模型進行修正和完善。設計任務管理子系統包括確定任務，分配任務，還包括權衡一致性、成本、性能等因素以及未來可擴充性。設計數據管理子系統，需要設計數據格式以及相應的服務，設計數據格式的方法與所用的數據存儲管理模式密切相關，不同數據存儲管理模式時，屬性和服務的設計方法是不同的。9.5.1系統分解系統分解即建立系統的體系結構，是設計比較復雜的系統時廣泛采用的戰略。把系統分解成若干個比較小的部分，然后再分別設計每個部分，這樣做有利于降低設計的難度，有利于軟件開發人員的分工協作，也有利于維護人員對系統理解和維護。系統的主要組成部分稱為子系統，通常根據所提供的功能來劃分子系統。子系統既不是一個對象也不是一個功能，而是類、關聯、操作、事件和約束的集合。各個子系統之間應該具有盡可能簡單、明確的接口。接口確定了交互形式和通過子系統邊界的信息流，但是無須規定子系統內部的實現算法。因此，可以相對獨立地設計各個子系統。229.5.1系統分解在劃分和設計子系統時，應該盡量減少子系統彼此間的依賴性。采用面向對象方法設計軟件系統時，面向對象設計模型針對與實現有關的因素而開展面向對象分析模型的5個活動（主題、類與對象、結構、屬性和服務），它包括問題域、人機交互、任務管理和數據管理等4個部分的設計，即針對這4大部分對應于組成目標系統的4個子系統---問題域子系統、人—機交互子系統、任務管理子系統和數據管理子系統進行設計。239.5.1系統分解24典型的面向對象設計模型9.5.1系統分解（1）問題域子系統把面向對象分析模型直接拿來，針對實現的要求進行必要的增補和調整，例如，需要對類、結構、屬性及服務進行分解和重組。這種分解是根據一定的過程標準來做的，標準包括可重用的設汁與編碼類，把問題域專用類組合在一起，通過增加一般類來創立約定，提供一個繼承性的支撐層次改善界面，提供存儲管理，以及增加低層細節等。（2）人機交互子系統包括有效的人機交互所需的顯示和輸入，這些類在很大程度上依賴于所用的圖形用戶界面環境，例如Windows、Delphi、C++，而且可能包括“窗口”、“菜單”、“滾動條”、“按鈕”等針對項目的特殊類。259.5.1系統分解（3）任務管理子系統包括任務的定義、通信和協調，以及硬件分配、外部系統及設備約定，可能包括的類有“任務”類和“任務協調”類。（4）數據管理子系統包括永久數據的存取，它隔離了物理的數據管理方法，無論是普通文件、帶標記語言的普通文件、關系型數據庫、面向對象數據庫等。可能包括的類有“存儲服務”，協調每個需永久保存的對象的存儲。

只有問題域子系統將面向對象分析模型直接取用，其他三個子系統則是面向對象分析階段未曾考慮的，全部在面向對象設計階段建立。269.5.2問題域子系統的設計問題域子系統也稱問題域部分。面向對象方法中的一個主要目標是保持問題域組織框架的完整性、穩定性，這樣可提高分析、設計到實現的追蹤性。因為系統的總體框架郜是建立在問題域基礎上的，所以，在設計與實現過程中細節無論做怎樣的修改，例如增加具體類、屬性或服務等，都不會影響開發結果的穩定性。穩定性是在類似系統中重用分析、設計和編程結果的關鍵因素。為更好地支持系統的擴充，也同樣需要穩定性。279.5.2問題域子系統的設計問題域子系統可以直接引用面向對象分析所得出的問題域精確對象模型，該模型提供了完整的框架，為設計問題域子系統奠定了良好的基礎，面向對象設計就應該保持該框架結構。只要可能，就應該保持面向對象分析所建立的問題域結構。通常，面向對象設計在分析模型的基礎上，從實現角度對問題域模型做一些補充或修改，修改包括增添、合并或分解類和對象、屬性及服務、調整繼承關系等。如果問題域子系統相當復雜龐大時，則應把它進一步分解成若干更小的子系統。289.5.2問題域子系統的設計為何對問題域子系統進行設計對描述系統時遇到的變動因素和穩定因素進行分析，是面向對象分析方法的基礎。系統需求中最容易變動的就是加工和子加工。與外界的接口同樣容易變動。數據管理中類的屬性和服務有時也在發生變化，而一些變動往往作用于一種對象。系統中最不容易對變動感知的穩定方面，一般是將問題空間當作整體看待的對象。基于問題域的總體結構框架是可以保持長期穩定的。這種穩定性是一個問題域的分析、設計及實現的結果，也是可以重用的關鍵。299.5.2問題域子系統的設計如何對問題域子系統進行設計在面向對象設計過程中，可能對面向對象分析所得出的問題域模型做的補充或修改如下：調整需求：當用戶需求或外部環境出現變化，或分析人員對問題理解出現偏差，導致建立了不能完整、準確反映用戶真實需求的面向對象分析模型時，需要對系統需求進行修改。309.5.2問題域子系統的設計②復用已有的類：設計時應該在面向對象分析基礎上實現現有類的復用。現有類時面向對象程序設計語言提供的類庫中的類。因此在設計階段就要開始考慮復用。復用已有類的過程如下：1.選擇可能被復用的現有類，標出現有類中對設計無用的屬性和服務，盡量復用那些使無用屬性和服務降到最低的類。2.從被復用的現有類中派生出問題域類。3.標出問題域類中從現有類繼承來的屬性和服務，在問題域類中無需定義它們。4.修改與問題域類相關的關聯，需要時改為與被復用的現有類相關的關聯。319.5.2問題域子系統的設計③把問題域類組合在一起：通常會引入一個根類將問題域類組合在一起。實際上這是在沒有更先進的組合機制可用時才采用的一種組合方法，此外這個根類還可以用來建立協議。④增添一般化類以建立協議：在面向對象設計的過程中，一些具體類往往需要一個公共的協議，即這些類都需要定義一組類似的服務，還可能定義相應的屬性。在這種情況下可以引入一個附加類，以便建立這個公共的協議。329.5.2問題域子系統的設計調整繼承層次：當模型的繼承模式與語言有偏差時，需要修改繼承模式。多重繼承模式單繼承模式339.5.3人機交互子系統的設計人機交互系統強調人如何命令系統以及系統如何向用戶提交信息，人們在使用計算機的過程中直觀感受到其對系統的接受程度。隨著計算機的普及，非專業人員開始使用計算機，人機交互系統更加關鍵。349.5.3人機交互子系統的設計在現在的大型軟件系統中，人機交互對象(類)通常是窗口或報告。軟件設計者至少要考慮以下3種窗口：

(1)安全/登錄窗口。這種窗口是用戶訪問系統的必經之路。

(2)設置窗口。這種窗口具有以下功能：①創建或初始化系統運行必需的對象。例如用來創建、維護和刪除持久對象的窗口。

持久對象類似于關系數據庫信息系統中的數據記錄。例如車輛、車主、銷售記錄

和事務。②系統管理功能，例如添加和刪除授權用戶，修改用戶使用系統的權限等。③啟動或關閉設備，例如啟動打印機等。(3)業務功能窗口。這種窗口用來幫助完成那些由信息系統和其用戶所進行的業務交互所必要的功能。例如，用于人機交互部件的登記、設置、車輛維修和安全事故的窗口。報告是另一種常用的形式，也屬于人機交互部件。報告對象(類)可以包括絕大多數用戶需要的信息，例如，登記、車輛維修、安全事故和繳費的報告。359.5.4任務管理子系統的設計通過面向對象分析建立的動態模型，是分析并發性的主要依據。如果兩個對象之間不存在交互，或同時接收事件，則這兩個對象本質上是并發的。通過檢查各個對象的狀態圖及他們之間交換的事件，能夠將若干個并發的對象歸并到一條控制線中。控制線是指一條遍及狀態圖集合的路徑，在這條路徑上每次只有一個對象是活動的。在計算機中用任務來實現控制線。對于某些任務來說，通過劃分任務可以簡化系統的總體設計和編碼工作，獨立任務可將必須并發執行的行為分離開來。這種并發行為可以在多個處理機上實現，也可以在運行多任務操作系統的單處理器上進行模擬。設計工作的一項重要內容，就是確定哪些是必須同時動作的對象，哪些是相互排斥的對象，從而進一步設計任務管理子系統。369.5.4任務管理子系統的設計常見的任務有事件驅動型任務、時鐘驅動型任務、優先任務、關鍵任務、協調任務等。設計任務管理子系統，包括確定各類任務并把任務分配給適當的硬件或軟件去執行。（1）確定事件驅動型任務。這類任務可能主要完成通信工作，如與設備、屏幕窗口、其他任務、子系統、另一個處理器或其他系統通信。例如，專門提供數據到達信號的任務，數據可能來自于終端也可能來自于緩沖區。（2）確定時鐘驅動型任務。某些任務每隔一定時間間隔就被觸發以執行某些處理。例如，某些設備需要周期性地獲得數據；某些人—機接口、子系統、任務、處理器或其他系統也可能需要周期性的通信。（3）確定優先任務。優先任務可以滿足高優先級或低優先級的處理需求。379.5.4任務管理子系統的設計（4）確定關鍵任務。關鍵任務是有關系統成功或失敗的關鍵處理，這類處理通常都有嚴格的可靠性要求。（5）確定協調任務。當系統中存在3個以上任務時，就應該增加一個任務，用它作為協調任務。（6）審查每個任務。對任務的性質進行仔細審查，去掉人為的、不必要的任務，使系統中包含的任務數保持到最少。（7）確定資源需求。設計者在決定到底采用軟件還是硬件的時候，必須綜合權衡一致性、成本、性能等多種因素，還要考慮未來的可擴充性和可修改性。（8）定義任務。說明任務的名稱，描述任務的功能、優先級，包含此任務的服務、任務與其他任務的協同方式以及任務的通信方式。389.5.5數據管理子系統的設計數據管理子系統是系統存儲或檢索對象的基本設施，它建立在某種數據存儲管理系統之上，并且隔離了數據存儲管理模式（文件、關系數據庫或面向對象數據庫）的影響，但實現細節集中在數據管理子系統中。這樣既有利于軟件的擴充、移植和維護，又簡化了軟件設計、編碼和測試的過程。設計數據管理子系統，既需要設計數據格式又需要設計相應的服務。399.5.5數據管理子系統的設計設計數據格式的方法與所使用的數據存儲管理模式密切相關，下面分別介紹每種管理模式的數據格式設計方法。（1）文件系統。

文件系統設計數據格式由以下步驟組成。定義第一范式表，列出每個類的屬性表并規范為第一范式。為每個第一范式表定義一個文件。測量性能和需要的存儲容量。修改原設計的第一范式，以滿足性能和存儲需求。409.5.5數據管理子系統的設計（2）關系數據庫管理系統。

關系數據庫管理系統設計數據格式由以下步驟組成。定義第三范式表為每個第三范式表定義一個數據庫表。測量性能和需要的存儲容量。修改先前設計的第三范式，以滿足性能和存儲需求。419.5.5數據管理子系統的設計（3）面向對象數據庫管理系統。

面向對象數據庫管理系統設計數據格式由以下步驟組成。擴展的關系數據庫途徑：使用與關系數據庫管理系統相同的方法。擴展的面向對象程序設計語言途徑：不需要規范化屬性的步驟，因為數據庫管理系統本身具有把對象值映射成存儲值的功能。429.5.5數據管理子系統的設計設計相應的服務如果某個類的對象需要存儲起來，則在這個類中增加一個屬性和服務，用于完成存儲對象自身的工作。應該把為此目的增加的屬性和服務作為“隱含”的屬性和服務，即無須在面向對象設計模型的屬性和服務層中顯式地表示它們，僅需在關于類與對象的文檔中描述它們。這樣設計之后，對象將知道怎樣存儲自己。用于“存儲自己”的屬性和服務，在問題域子系統和數據管理子系統之間構成一座必要的橋梁。利用多重繼承機制，可以在某個適當的基類中定義這樣的屬性和服務，然后，如果某個類的對象需要長期存儲，該類就從基類中繼承這樣的屬性和服務。這樣設計后，對象將知道如何存儲自己。439.5.5數據管理子系統的設計數據存放設計是按照文件、關系數據庫或面向對象數據庫來設計數據的存放。1．采用文件進行數據管理

被存儲的對象需要知道打開哪個（些）文件，怎樣把文件定位到正確的記錄上，怎樣檢索出舊值（如果有的話），以及怎樣用現有值更新它們。此外，還應該定義一個ObjectServer（對象服務器）類，并創建它的實例。該類提供下列服務：通知對象保存自身；檢索已存儲的對象（查找，讀值，創建并初始化對象），以便把這些對象提供給其他子系統使用。449.5.5數據管理子系統的設計2．采用關系數據庫進行數據管理被存儲的對象應該知道訪問哪些數據庫表，怎樣訪問所需要的行，怎樣檢索出舊值（如果有的話），以及怎樣用現有值更新它們。此外，還應該定義一個ObjectServer類，并聲明它的對象。該類提供下列服務：通知對象保存自身；檢索已存儲的對象（查找，讀值，創建并初始化對象），以便由其他子系統使用這些對象。459.5.5數據管理子系統的設計

3．采用面向對象數據庫進行數據管理（1）擴展的關系數據庫途徑：方法與使用關系數據庫管理系統時的方法相同。（2）擴展的面向對象程序設計語言途徑：這種數據庫管理系統已經給每個對象提供了“存儲自己”的行為，無須增加服務。由于有面向對象數據庫管理系統負責存儲和恢復這類對象，因此，只需給需要長期保存的對象加個標記。469.5.5數據管理子系統的設計數據管理子系統主要實現以下目標：存儲問題域的持久對象（類），對于那些在系統中兩次調用之間需要保存的對象，數據管理子系統提供了與操作平臺數據管理存儲系統之間的接口。這樣做使得數據管理子系統將系統中的數據存儲、恢復和更新與其他部分分離開來，提高可移植性與可維護性。數據管理子系統為問題域中所有的持久對象封裝了查找和存儲機制。

需要數據管理子系統的主要原因是針對對象模型在多種硬件、軟件和數據管理平臺上的可維護性。從理論上說對象模型的運行方式就像“即插即用”479.6對象設計對象設計在系統設計完成之后進行，對象設計以問題域的對象設計為核心，其結果是一個詳細的對象模型。經過多次反復的分析和系統設計之后，設計者通常會發現有些內容沒有考慮到。這些沒有考慮到的內容，會在對象設計的過程中被發現。這個設計過程包括標識新的解決方案對象、調整購買到的商業化構件、對每個子系統接口的精確說明和類的詳細說明。489.6對象設計面向對象分析得出的對象模型，通常并不詳細描述類中的服務。面向對象設計則是擴充、完善和細化面向對象分析模型的過程，設計類中的服務、實現服務的算法是面向對象設計的重要任務，還要設計類的關聯、接口形式以及設計的優化。對象設計的內容包括：對象中對屬性和操作的詳細描述；對象之間發送消息的協議；類之間的各種關系的定義；對象之間的動態交互行為等。499.6.1設計類中的服務面向對象分析得出的對象模型，通常并不詳細描述類中的服務。面向對象設計則是擴充、完善和細化面向對象分析模型的過程，所以，詳細描述類中的服務是面向對象設計的重要任務。1.確定類中應有的服務從對象模型中引入服務：系統的對象、屬性和服務中直接引用。從動態模型中確定服務：從狀態圖中可以提取服務。從功能模型中確定服務：從數據流圖中可以提取服務。

2.設計實現服務的方法設計實現服務的算法：需考慮算法復雜度，容易理解和實現以及修改。選擇數據結構：選擇能方便、有效實現算法的物理數據結構。定義內部類和內部操作：存放中間結果，或用低層操作分解高層操作。509.6.2設計類的關聯在對象模型中，關聯是連接不同對象的紐帶，它指定了對象相互間的訪問路徑。在面向對象設計過程中，設計人員必須確定實現關聯的具體策略。既可以選定一個全局性的策略統一實現所有關聯，也可以分別為每個關聯選擇具體的實現策略，以與它在應用系統中的使用方式相適應。關聯的遍歷：在系統中用單向遍歷和雙向遍歷來使用關聯。單向遍歷的關聯可以用指針來實現。如果關聯的階是一元的，則可以用一個簡單指針來實現，多元關聯則用指針集合來實現。51指針實現單向關聯9.6.2設計類的關聯52指針實現雙向關聯9.6.2設計類的關聯雙向關聯有3種方法1.只用屬性實現一個方向的關聯，需要反向遍歷時就執行一次正向查找。適用于兩個方向遍歷的頻度相差較大，且需要盡量減少存儲和修改的開銷。2.雙向關聯都用屬性實現，可以實現快速的訪問，適用于屬性修改很少的關聯。3.用獨立關聯對象實現，關聯對象是獨立的關聯類的實例，不屬于任何相互關聯的類。539.6.2設計類的關聯鏈屬性的實現

實現鏈屬性的方法取決于關聯的階數。一對一關聯的鏈屬性可作為其中一個對象的屬性存儲在該對象中；對于一對多關聯來說，鏈屬性可作為“多”端對象的一個屬性；如果是多對多關聯，則通常使用一個獨立的類來實現鏈屬性，鏈屬性不可能只與一個關聯對象有關，這個類的每個實例表示一條鏈及該鏈的屬性。549.6.2設計類的關聯55對象實現關聯學校與學生教師學生課程學校學生9.6.3對象設計優化1.確定優先級

系統的各項質量指標并不是同等重要的，設計人員必須確定各