11面向對象設計3

1、面向對象設計第十一章2022/8/111面向對象設計的含義分析是提取和整理用戶需求，并建立問題域精確模型的過程。設計是把分析階段得到的需求轉變成符合成本和質量要求的、抽象的系統(tǒng)實現(xiàn)方案的過程。從面向對象分析到面向對象設計(OOD)，是一個逐漸擴充模型的過程。面向對象設計就是用面向對象觀點建立求解域模型的過程。2022/8/112分析與設計的關聯(lián)二者界限模糊，分析和設計活動是一個多次反復迭代的過程：許多分析結果可以直接映射成設計結果設計過程中會加深、補充對系統(tǒng)需求的理解，從而進一步完善分析結果。面向對象方法學：在概念和表示方法上的一致性，保證了在各項開發(fā)活動之間的平滑(無縫)過渡。領域專家和開發(fā)

2、人員能夠比較容易地跟蹤整個系統(tǒng)開發(fā)過程，這是面向對象方法與傳統(tǒng)方法比較起來的一大優(yōu)勢。2022/8/113主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/114優(yōu)秀設計的含義所謂優(yōu)秀設計，是權衡了各種因素，從而使得系統(tǒng)在其整個生命周期中的總開銷最小的設計。優(yōu)秀軟件設計的一個主要特點就是容易維護。2022/8/115傳統(tǒng)軟件工程與OO的設計原理傳統(tǒng)軟件工程的總體設計中有以下基本原理與相關概念：模塊化抽象逐步求精信息隱藏和局部化模塊獨立面向對象設計準則：模塊化抽象信息隱藏弱耦合強內聚

3、可重用2022/8/116主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/117面向對象方法學的啟發(fā)規(guī)則面向對象方法學的啟發(fā)式規(guī)則：設計結果應該清晰易懂一般-特殊結構的深度應適當設計簡單的類使用簡單的協(xié)議使用簡單的服務把設計變動減至最小2022/8/118面向對象方法學的啟發(fā)規(guī)則比較：傳統(tǒng)軟件工程的總體設計（第5章）的啟發(fā)規(guī)則：改進軟件結構提高模塊獨立性模塊規(guī)模應該適中深度、寬度、扇出和扇入都應適當模塊的作用域應在控制域內力爭降低模塊接口的復雜程度設計單入口單出口的模塊模塊功能應

4、該可以預測2022/8/119主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/1110“軟件重用”主要內容概述類構件軟件重用的效益2022/8/1111重用的含義重用也叫再用或復用，是指同一事物不作修改或稍加改動就多次重復使用。軟件重用可分為以下3個層次：知識重用(例如，軟件工程知識的重用)。方法和標準的重用(例如，面向對象方法或國家制定的軟件開發(fā)規(guī)范的重用)。軟件成分的重用。前兩個重用層次屬于知識工程研究的范疇，本節(jié)僅討論軟件成分重用問題。2022/8/1112軟件成分的重用級

5、別軟件成分的重用可以進一步劃分成以下3個級別：代碼重用。談論最多的， 通常理解為調用庫中的模塊。設計結果重用。重用某個軟件系統(tǒng)的設計模型(即求解域模型)。這個級別的重用有助于把一個應用系統(tǒng)移植到完全不同的軟硬件平臺上。分析結果重用。這是更高級別的重用，即重用某個系統(tǒng)的分析模型。它特別適用于用戶需求未改變，但系統(tǒng)體系結構發(fā)生了根本變化的場合。2022/8/1113典型的可重用軟件成分 項目計劃。 成本估計。 體系結構。 需求模型和規(guī)格說明。 設計。 源代碼。 用戶文檔和技術文檔。 用戶界面。 數(shù)據(jù)。測試用例。2022/8/1114“軟件重用”主要內容概述類構件軟件重用的效益2022/8/1115

6、類構件利用面向對象技術，可以更方便更有效地實現(xiàn)軟件重用。面向對象技術中的“類”，是比較理想的可重用軟構件，不妨稱之為類構件。2022/8/1116可重用軟構件應具備的特點可重用軟構件應具備的特點：模塊獨立性強。具有高度可塑性。接口清晰、簡明、可靠。精心設計的“類”基本上能滿足上述要求，可以認為它是可重用軟構件的雛形。2022/8/1117類構件的重用方式實例重用繼承重用多態(tài)重用2022/8/1118實例重用的形式最基本的重用方式：由于類的封裝性，使用者無須了解實現(xiàn)細節(jié)就可以使用適當?shù)臉嬙旌瘮?shù)，按照需要創(chuàng)建類的實例。然后向所創(chuàng)建的實例發(fā)送適當?shù)南?，啟動相應的服務，完成需要完成的工作。另一種形式

7、：用幾個簡單的對象作為類的成員創(chuàng)建出一個更復雜的類，這是實例重用的2022/8/1119設計類構件的困難雖然實例重用是最基本的重用方法，但設計出一個理想的類構件并不是一件容易的事情。例如：決定一個類對外提供多少服務就是一種相當困難的事。提供的服務過多，會增加接口復雜度，也會使類構件變得難于理解。提供的服務過少，則會因為過分一般化而失去重用價值。每個類構件的合理服務數(shù)都與具體應用環(huán)境密切相關，因此找到一個合理的折衷值是相當困難的。2022/8/1120類構件的重用方式實例重用繼承重用多態(tài)重用2022/8/1121繼承重用面向對象方法特有的繼承性提供了一種對已有的類構件進行裁剪的機制。當已有的類構

8、件不能通過實例重用完全滿足當前系統(tǒng)需求時，繼承重用提供了一種安全地修改已有類構件，以便在當前系統(tǒng)中重用的手段。2022/8/1122實現(xiàn)繼承重用的關鍵點為提高繼承重用的效果，關鍵是設計一個合理的、具有一定深度的類構件繼承層次結構。這樣做的好處是：每個子類在繼承父類的屬性和服務的基礎上，只加入少量新屬性和新服務，這就不僅降低了每個類構件的接口復雜度，表現(xiàn)出一個清晰的進化過程，提高了每個子類的可理解性，而且為軟件開發(fā)人員提供了更多可重用的類構件。必要時應在領域專家?guī)椭?，建立符合領域知識的繼承層次。為多態(tài)重用奠定了良好基礎。2022/8/1123類構件的重用方式實例重用繼承重用多態(tài)重用2022/8

9、/1124多態(tài)重用利用多態(tài)性不僅可以使對象的對外接口更加一般化(基類與派生類的許多對外接口是相同的)，從而降低了消息連接的復雜程度，而且還提供了一種簡便可靠的軟構件組合機制。系統(tǒng)運行時，根據(jù)接收消息的對象類型，由多態(tài)性機制啟動正確的方法，去響應一個一般化的消息，從而簡化了消息界面和軟構件連接過程。2022/8/1125可能影響重用的操作為充分實現(xiàn)多態(tài)重用，在設計類構件時，應該把注意力集中在下列一些可能影響重用性的操作上：與表示方法有關的操作。例如，不同實例的比較、顯示、擦除等。與數(shù)據(jù)結構、數(shù)據(jù)大小等有關的操作。與外部設備有關的操作。例如，設備控制。實現(xiàn)算法在將來可能會改進(或改變)的核心操作2

10、022/8/1126利用適配接口實現(xiàn)類構件的重用如果不預先采取適當措施，前述操作會妨礙類構件的重用。因此，必須把它們從類的操作中分離出來，作為“適配接口”。例如，假設類C具有操作M1, M2, Mn,和操作A1, A2, Ak,其中：Aj是(1jk)是上面列出的可能影響類C重用的幾類操作，Mi是(1in)是其他操作。如果Mi通過調用適配接口Aj而實現(xiàn)，則實際上M被A參數(shù)化了。在不同應用環(huán)境下，用戶只需在派生類中重新定義Aj(1jk)就可以重用類C。2022/8/1127把適配接口細分為轉換接口和擴充接口可把適配接口細分為轉換接口和擴充接口。轉換接口是為了克服與表示方法、數(shù)據(jù)結構或硬件特點相關的

11、操作給重用帶來的困難而設計的。這類接口是每個類構件在重用時都必須重新定義的服務的集合。當使用C+編程時，應該在根類(或適當?shù)幕?中，把屬于轉換接口的服務定義為純虛函數(shù)。如果某個服務有多種可能的實現(xiàn)算法，則應該把它當作擴充接口。擴充接口與轉換接口不同，并不需要強迫用戶在派生類中重新定義它們，相反，如果在派生類中沒有給出擴充接口的新算法，則將繼承父類中的算法。當使用C+編程時，在基類中把這類服務定義為普通的虛函數(shù)。2022/8/1128“軟件重用”主要內容概述類構件軟件重用的效益2022/8/1129軟件重用的效益近來，軟件產(chǎn)業(yè)界的實例研究表明，通過積極的軟件重用能夠獲得可觀的商業(yè)效益，產(chǎn)品質量

12、、開發(fā)生產(chǎn)率和整體成本都得到改善。軟件重用的效益可表現(xiàn)在以下幾個方面：質量生產(chǎn)率成本2022/8/1130軟件重用的效益-1質量理想狀態(tài)下，為了重用而開發(fā)的軟構件已被證明是正確的，且沒有缺陷。事實上，由于不能定期進行形式化驗證，錯誤可能而且也確實存在。但是，隨著每一次重用，都會有一些錯誤被發(fā)現(xiàn)并被清除，構件的質量也會隨之改善。隨著時間的推移，構件將變成實質上無錯誤的。HP公司經(jīng)研究發(fā)現(xiàn)，被重用的代碼的錯誤率是每千行代碼中有0.9個錯誤，而新開發(fā)的軟件的錯誤率是每千行代碼中有4.1個錯誤。對于一個包含68%重用代碼的應用系統(tǒng)，錯誤率大約是每千行2.0個錯誤，與不使用重用的開發(fā)相比錯誤率降低了51

13、%。Henry和Faller報告說，使用重用的開發(fā)可使軟件質量改進35%。雖然不同研究者報告的改善率并不完全相同，但偏差均合理。公正地說，重用確實能給軟件產(chǎn)品的質量和可靠性帶來實質性的提高。2022/8/1131軟件重用的效益-2生產(chǎn)率當把可重用的軟件成分應用于軟件開發(fā)的全過程時，創(chuàng)建計劃、模型、文檔、代碼和數(shù)據(jù)所需花費的時間將減少，從而將用較少的投入給客戶提供相同級別的產(chǎn)品，因此，生產(chǎn)率得到了提高。由于應用領域、問題復雜程度、項目組的結構和大小、項目期限、可應用的技術等許多因素都對項目組的生產(chǎn)率有影響，因此，不同開發(fā)組織對軟件重用帶來生產(chǎn)率提高的數(shù)字的報告并不相同，但基本上30%50%的重用

14、大約可以導致生產(chǎn)率提高25%40%。2022/8/1132軟件重用的效益-3成本軟件重用能節(jié)省的凈成本節(jié)省可估算為：C=Cs-Cr-CdCs是項目從頭開發(fā)（沒有重用）時所需要的成本； Cr是與重用相關聯(lián)的成本；Cd是交付給客戶的軟件的實際成本。可使用一定的技術來估算Cs，而與重用相關聯(lián)的成本Cr主要包括：領域分析與建模的成本；設計領域體系結構的成本；為便于重用而增加的文檔的成本；維護和完善可重用的軟件成分的成本；為從外部獲取構件所付出的版稅和許可證費；創(chuàng)建（或購買）及運行重用庫的費用；對設計和實現(xiàn)可重用構件的人員的培訓費用。雖然和領域分析及運行重用庫相關聯(lián)的成本可能相當高，但是它們可以由許多項

15、目分攤。上面列出的很多其他成本所解決的問題，實際上是良好軟件工程實踐的一部分，不管是否考慮重用，這些問題都應該解決。2022/8/1133主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/1134系統(tǒng)分解與子系統(tǒng)在設計比較復雜的應用系統(tǒng)時普遍采用的策略，是首先把系統(tǒng)分解成若干個比較小的部分，然后再分別設計每個部分。系統(tǒng)的主要組成部分稱為子系統(tǒng)：通常根據(jù)所提供的功能來劃分子系統(tǒng)。一般說來，子系統(tǒng)的數(shù)目應該與系統(tǒng)規(guī)模基本匹配。各個子系統(tǒng)之間應該具有盡可能簡單、明確的接口。接口確定了交互

16、形式和通過子系統(tǒng)邊界的信息流，但是無須規(guī)定子系統(tǒng)內部的實現(xiàn)算法。因此，可以相對獨立地設計各個子系統(tǒng)。在劃分和設計子系統(tǒng)時，應該盡量減少子系統(tǒng)彼此間的依賴性。2022/8/1135面向對象設計模型5個層次：與面向對象分析模型(即問題域的對象模型)一樣，面向對象設計模型(即求解域的對象模型)，也由5個層次組成：主題、類與對象、結構、屬性、服務這5個層次一層比一層表示的細節(jié)更多，可以把這5個層次想象為整個模型的水平切片。2022/8/1136面向對象設計模型大多數(shù)系統(tǒng)的面向對象設計模型：在邏輯上由4部分組成：人機交互部分、問題域部分、任務管理部分、數(shù)據(jù)管理部分這4部分對應于組成目標系統(tǒng)的4個子系統(tǒng)：

17、問題域子系統(tǒng)、人機交互子系統(tǒng)、任務管理子系統(tǒng)、數(shù)據(jù)管理子系統(tǒng)不同的軟件系統(tǒng)中，這4個子系統(tǒng)的重要程度和規(guī)?？赡芟嗖詈艽螅阂?guī)模過大的在設計過程中應該進一步劃分成更小的子系統(tǒng)。規(guī)模過小的可合并在其他子系統(tǒng)中，某些領域的應用系統(tǒng)在邏輯上可能僅由3個(甚至少于3個)子系統(tǒng)組成。2022/8/11375個層次與4大組成部分的關系可以把面向對象設計模型的4大組成部分想象成整個模型的4個垂直切片。典型的面向對象設計模型可以用下圖表示：2022/8/1138子系統(tǒng)之間的交互方式軟件系統(tǒng)中，子系統(tǒng)之間的交互有兩種可能方式:客戶-供應商(Client-supplier)關系。平等伙伴(peer-to-peer)關

18、系?？偟恼f來，單向交互比雙向交互更容易理解，也更容易設計和修改，因此應該盡量使用客戶-供應商關系。2022/8/1139組織系統(tǒng)的方案把子系統(tǒng)組織成完整的系統(tǒng)，有兩種方案：水平層次組織垂直塊狀組織2022/8/1140組織系統(tǒng)的方案-1水平層次組織把軟件系統(tǒng)組織成一個層次系統(tǒng)，每層是一個子系統(tǒng)。上層在下層的基礎上建立，下層為實現(xiàn)上層功能而提供必要的服務。每一層內所包含的對象，彼此間相互獨立，而處于不同層次上的對象，彼此間往往有關聯(lián)。實際上，在上、下層之間存在客戶-供應商關系。2022/8/1141層次結構可劃分為封閉式和開放式層次結構又可進一步劃分成兩種模式：封閉式：每層子系統(tǒng)僅僅使用其直接下

19、層提供的服務。降低了各層次之間的相互依賴性，更容易理解和修改。開放模式：某層子系統(tǒng)可以使用處于其下面的任何一層子系統(tǒng)所提供的服務。優(yōu)點，是減少了需要在每層重新定義的服務數(shù)目。開放模式的系統(tǒng)不適合信息隱藏原則。設計軟件系統(tǒng)時到底采用哪種結構模式，需要權衡效率和模塊獨立性等多種因素，通盤考慮后再做決定。2022/8/1142系統(tǒng)頂層和底層的關系通常，在需求陳述中只描述了對系統(tǒng)頂層和底層的需求：頂層就是用戶看到的目標系統(tǒng)；底層則是可以使用的資源。頂層和底層往往差異很大，設計者必須設計一些中間層次，以減少不同層次之間的概念差異。2022/8/1143組織系統(tǒng)的方案-2塊狀組織這種組織方案把軟件系統(tǒng)垂直

20、地分解成若干個相對獨立的、弱耦合的子系統(tǒng)，一個子系統(tǒng)相當于一塊，每塊提供一種類型的服務。2022/8/1144層次和塊的混合結構利用層次和塊的各種可能的組合，可以成功地由多個子系統(tǒng)組成一個完整的軟件系統(tǒng)。當混合使用層次結構和塊狀結構時，同一層次可以由若干塊組成，而同一塊也可以分為若干層。如圖表示一個典型的應用系統(tǒng)的組織結構，這個應用系統(tǒng)采用了層次與塊狀的混合結構。2022/8/1145NET Framework與VS.NET最上面是語言層。CLS：支持多種語言，只要支持通用語言規(guī)范的語言它都支持。ASP .NET是基于Web開發(fā)技術的核心，Windows Forms類似一個弱化的MFC（企業(yè)及

21、網(wǎng)絡應用中，Rich Client UI不再是重要組成部分，基于Web的方式將成為主流）Operating SystemCommon Language RuntimeADO.NET: Data and XMLASP.NET: Web Services & Web FormsWindowsFormsCommon Language SpecificationVisual Studio.NETVBC+C#JScriptADO.NET提供全面的數(shù)據(jù)及XML訪問技術，微軟的UDA（統(tǒng)一數(shù)據(jù)訪問）思想在這里充分得到體現(xiàn)。Database、XML在這里得到充分集成，隨著SQL Server下一版本的推出，X

22、ML與數(shù)據(jù)庫將充分融合成為XML DB。CLR為所有的語言支持垃圾收集，線程管理等功能OS。VS .NET在一個整合的IDE中為.NET Framework提供了一個簡單易用、整合企業(yè)建模工具的綜合開發(fā)工具，當Linux還在追求User Friendly的時候，微軟早已經(jīng)進入了Developer Friendly的時代。好處：降低總擁有成本。2022/8/1146設計系統(tǒng)的拓撲結構由子系統(tǒng)組成完整的系統(tǒng)時，典型的拓撲結構有：管道形樹形星形設計者應該采用與問題結構相適應的、盡可能簡單的拓撲結構，以減少子系統(tǒng)之間的交互數(shù)量。2022/8/1147主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設

23、計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/1148分析與設計使用OO方法開發(fā)軟件時，分析與設計之間并沒有明確的分界線，對于問題域子系統(tǒng)來說，情況更是如此。分析與設計畢竟是性質不同的兩類開發(fā)工作：分析工作可以而且應該與具體實現(xiàn)無關；設計工作則在很大程度上受具體實現(xiàn)環(huán)境的約束。在開始進行設計工作之前(至少在完成設計之前)，設計者應該了解：本項目預計要使用的編程語言可用的軟構件庫(主要是類庫)程序員的編程經(jīng)驗2022/8/1149問題域模型在OO設計中的作用通過面向對象分析所得出的問題域精確模型，為設計問題域子系統(tǒng)奠定了良好的基礎

24、，建立了完整的框架。只要可能，就應該保持面向對象分析所建立的問題域結構。通常，面向對象設計僅需從實現(xiàn)角度對問題域模型做一些補充或修改，主要是增添、合并或分解類與對象、屬性及服務，調整繼承關系等等。當問題域子系統(tǒng)過分復雜龐大時，應該把它進一步分解成若干個更小的子系統(tǒng)。2022/8/1150OO可以保持問題域組織框架的穩(wěn)定性使用面向對象方法學開發(fā)軟件，能夠保持問題域組織框架的穩(wěn)定性，從而便于追蹤分析、設計和編程的結果。在設計與實現(xiàn)過程中所做的細節(jié)修改(例如，增加具體類，增加屬性或服務)，并不影響開發(fā)結果的穩(wěn)定性，因為系統(tǒng)的總體框架是基于問題域的。對于需求可能隨時間變化的系統(tǒng)來說，穩(wěn)定性是至關重要的

25、。穩(wěn)定性能夠在類似系統(tǒng)中重用分析、設計和編程結果的關鍵因素。為更好地支持系統(tǒng)在其生命周期中的擴充，也需要穩(wěn)定性。2022/8/1151對問題域模型需要做的補充或修改調整需求。有兩種情況：重用已有的類把問題域類組合在一起增添一般化類以建立協(xié)議調整繼承層次2022/8/1152補充或修改-1調整需求有兩種情況會導致修改通過面向對象分析所確定的系統(tǒng)需求：用戶需求或外部環(huán)境發(fā)生了變化；面向對象分析模型不能完整、準確地反映用戶的真實需求。無論上述哪種情況，通常只需要：簡單地修改面向對象分析結果；然后再把這些修改反映到問題域子系統(tǒng)中。2022/8/1153補充或修改-2重用已有的類代碼重用從設計階段開始，

26、在研究OOA結果時就應該尋找使用已有類的方法。若因為沒有合適的類可以重用而確實需要創(chuàng)建新的類，則在設計這些新類的協(xié)議時，必須考慮到將來的可重用性。如果有可能重用已有的類，則重用已有類的典型過程如下：選擇有可能被重用的已有類，標出這些候選類中對本問題無用的屬性和服務，盡量重用那些能使無用的屬性和服務降到最低程度的類。在被重用的已有類和問題域之間添加泛化關系(即從被重用的已有類派生出問題域類)。標出問題域類中從已有類繼承業(yè)的屬性和服務，現(xiàn)在已經(jīng)無須在問題域類內定義它們了。修改與問題域類相關的關聯(lián)，必要時改為與被重用的已有類相關的關聯(lián)。2022/8/1154補充或修改-3把問題域類組合在一起在面向對

27、象設計過程中，設計者往往通過引入一個根類而把問題域類組合在一起。事實上，這是在沒有更先進的組合機制可用時才采用的一種組合方法。此外，這樣的根類還可以用來建立協(xié)議。2022/8/1155補充或修改-4增添一般化類以建立協(xié)議在設計過程中，常有一些具體類需要一個公共的協(xié)議，即需要定義一組類似的服務。在這種情況下可以引入一個附加類(例如，根類)，以便建立這個協(xié)議(即命名公共服務集合，這些服務在具體類中仔細定義)。2022/8/1156補充或修改-5調整繼承層次如果OOA模型中包含了多重繼承關系，然而所使用的程序設計語言卻并不提供多重繼承機制，則必須修改OOA的結果。即使使用支持多重繼承的語言，有時也會

28、出于實現(xiàn)考慮而對OOA結果作一些調整。使用多重繼承機制。使用多重繼承機制時，應該避免出現(xiàn)屬性及服務的命名沖突。使用單繼承機制。如果打算使用僅提供單繼承機制的語言實現(xiàn)系統(tǒng)，則必須把OOA模型中的多重繼承結構轉換成單繼承結構。2022/8/1157屬性及服務命名沖突右圖是稱為窄菱形模式的多重繼承模式。使用這種模式時出現(xiàn)屬性及服務命名沖突的可能性比較大。2022/8/1158避免出現(xiàn)屬性及服務命名沖突的方法右圖是稱為闊菱形模式的多重繼承模式，這種模式的屬性及服務的名字發(fā)生沖突的可能性比較小，但是，它需要用更多的類才能表示同一個設計。2022/8/1159多重繼承結構轉換成單繼承結構的方法如果打算使用

29、僅提供單繼承機制的語言實現(xiàn)系統(tǒng)，則必須把OOA模型中的多重繼承結構轉換成單繼承結構。如圖所示把多重繼承結構簡化成單一的單繼承層次結構。顯然，在多重繼承結構中的某些繼承關系，經(jīng)簡化后將不再存在，這表明需要在各個具體類中重復定義某些屬性和服務。2022/8/1160ATM系統(tǒng)實例如圖描繪了ATM系統(tǒng)的問題域子系統(tǒng)的結構：把ATM系統(tǒng)劃分成3個子系統(tǒng)：ATM站、中央計算機、分行計算機。3個子系統(tǒng)的拓撲結構為星形，以中央計算機為中心向外幅射，同所有ATM站及分行計算機通信。物理聯(lián)結用專用電話線。根據(jù)ATM站號和分行代碼，區(qū)分由每個ATM站和每臺分行計算機聯(lián)向中央計算機的電話線。2022/8/1161A

30、TM系統(tǒng)實例的補充說明由于在OOA過程中已對ATM系統(tǒng)做了相當仔細的分析而且假設所使用的實現(xiàn)環(huán)境完全支持OOA模型的實現(xiàn)因此，在面向對象設計階段無須對已有的問題域模型作實質性的修改或擴充。2022/8/1162主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/1163設計人機交互子系統(tǒng)的內容與步驟在OOA過程中，已對用戶界面需求做了初步分析。在OOD過程中，應該對系統(tǒng)的人機交互子系統(tǒng)進行詳細設計，以確定人機交互的細節(jié)，其中包括指定窗口和報表的形式、設計命令層等項內容。利用OOD設計

31、人機交互子系統(tǒng)的步驟：分類用戶描述用戶設計命令層次設計人機交互類2022/8/1164人機交互子系統(tǒng)1分類用戶人機交互界面是給用戶用的，設計者應該認真研究這些用戶。在深入現(xiàn)場過程中，設計者應該認真思考下述問題：用戶必須完成哪些工作？設計者能夠提供什么工具來支持這些工作的完成？怎樣使得這些工具使用起來更方便更有效？通常從下列幾個不同角度對用戶進行分類：按技能水平分類(新手、初級、中級、高級)。按職務分類(總經(jīng)理、經(jīng)理、職員)。按所屬集團分類(職員、顧客)。2022/8/1165人機交互子系統(tǒng)-2描述用戶描述用戶信息有：用戶類型。使用系統(tǒng)欲達到的目的。特征(年齡、性別、受教育程度、限制因素等)。關

32、鍵的成功因素(需求、愛好、習慣等)。技能水平。完成本職工作的腳本。2022/8/1166人機交互子系統(tǒng)-3設計命令層次設計命令層次的工作通常包含以下內容：研究現(xiàn)有的人機交互含義和準則確定初始的命令層次精化命令層次。應該考慮下列一些因素：2022/8/1167人機交互子系統(tǒng)-3設計命令層次現(xiàn)在，Windows已經(jīng)成為微機圖形用戶界面事實上的工業(yè)標準。所有Windows應用程序的基本外觀及給用戶的感受都是相同的。Windows程序通常還遵守廣大用戶習以為常的許多約定。設計圖形用戶界面時，應該保持與普通Windows應用程序界面相一致，并遵守廣大用戶習慣的約定，這樣才會被用戶接受和喜愛。2022/8

33、/1168人機交互子系統(tǒng)-3設計命令層次所謂命令層次，實質上是用過程抽象機制組織起來的、可供選用的服務的表示形式。設計命令層次時，通常先從對服務的過程抽象著手，然后再進一步修改它們，以適合具體應用環(huán)境的需要。2022/8/1169人機交互子系統(tǒng)-3設計命令層次為進一步修改完善初始的命令層次，應該考慮下列一些因素：次序：仔細選擇每個服務的名字，并在命令層的每一部分內把服務排好次序。整體-部分關系：尋找在這些服務中存在的整體-部分模式，這樣做有助于在命令層中分組組織服務。寬度和深度：命令層次的寬度和深度都不應該過大。操作步驟：應該用盡量少的單擊、拖動和擊鍵組合來表達命令，而且應該為高級用戶提供簡捷

34、的操作方法。2022/8/1170人機交互子系統(tǒng)-4設計人機交互類人機交互類與所使用的操作系統(tǒng)及編程語言密切相關。例如，在Windows環(huán)境下運行的Visual C+語言提供了MFC類庫，設計人機交互類時，往往僅需從MFC類庫中選出一些適用的類，然后從這些類派生出符合自己需要的類就可以了。2022/8/1171主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/1172任務管理與對象任一“任務”都是由各個“對象”協(xié)同工作完成的，不同的任務標識了必須同時發(fā)生的不同行為。所以任務管理時要

35、特別考慮對象之間的協(xié)調，特別是那些需要并發(fā)工作的對象、存在相互依賴的對象：因此，設計“任務管理子系統(tǒng)”時：一項重要內容就是：確定哪些是必須同時動作的對象，哪些是相互排斥的對象。然后進一步設計任務管理子系統(tǒng)。即如教材中所敘述的，分為以下兩步：分析并發(fā)性設計任務管理子系統(tǒng)2022/8/1173并發(fā)的含義通過面向對象分析建立起來的動態(tài)模型，是分析并發(fā)性的主要依據(jù)。如果兩個對象彼此間不存在交互，或者它們同時接受事件，則這兩個對象在本質上是并發(fā)的。2022/8/1174控制線的含義通過檢查各個對象的狀態(tài)圖及它們之間交換的事件，能夠把若干個非并發(fā)的對象歸并到一條控制線中。所謂控制線，是一條遍及狀態(tài)圖集合的

36、路徑，在這條路徑上每次只有一個對象是活動的。在計算機系統(tǒng)中用任務(task)實現(xiàn)控制線，一般認為任務是進程(process)的別名。通常把多個任務的并發(fā)執(zhí)行稱為多任務。2022/8/1175任務與并發(fā)的關系對于某些應用系統(tǒng)來說，通過劃分任務，可以簡化系統(tǒng)的設計及編碼工作。不同的任務標識了必須同時發(fā)生的不同行為。這種并發(fā)行為既可以在不同的處理器上實現(xiàn)，也可以在單個處理器上利用多任務操作系統(tǒng)仿真實現(xiàn)(通常采用時間分片策略仿真多處理器環(huán)境)。2022/8/1176設計任務管理子系統(tǒng)常見的任務常見的任務有：事件驅動型任務時鐘驅動型任務優(yōu)先任務關鍵任務協(xié)調任務2022/8/1177設計任務管理子系統(tǒng)的工

37、作內容設計任務管理子系統(tǒng)，包括：確定各類任務把任務分配給適當?shù)挠布蜍浖?zhí)行2022/8/1178事件驅動型任務的意義某些任務是由事件驅動的，這類任務可能主要完成通信工作。例如，與設備、屏幕窗口、其他任務、子系統(tǒng)、另一個處理器或其他系統(tǒng)通信。事件通常是表明某些數(shù)據(jù)到達的信號。2022/8/1179事件驅動型任務的工作過程在系統(tǒng)運行時，事件驅動型任務的工作過程如下：任務處于睡眠狀態(tài)(不消耗處理器時間)，等待來自數(shù)據(jù)線或其他數(shù)據(jù)源的中斷；一旦接收到中斷就喚醒了該任務：接收數(shù)據(jù)把數(shù)據(jù)放入內存緩沖區(qū)或其他目的地通知需要知道這件事的對象該任務又回到睡眠狀態(tài)。2022/8/1180“時針驅動”的含義某些

38、任務每隔一定時間間隔就被觸發(fā)以執(zhí)行某些處理。例如：某些設備需要周期性地獲得數(shù)據(jù)某些人機接口、子系統(tǒng)、任務、處理器或其他系統(tǒng)也可能需要周期性地通信在這些場合往往需要使用時鐘驅動型任務。2022/8/1181時鐘驅動型任務的工作過程時鐘驅動型任務的工作過程如下：任務設置了喚醒時間；任務進入睡眠狀態(tài)；任務睡眠(不消耗處理器時間)，等待來自系統(tǒng)的中斷；一旦接收到中斷，任務就被喚醒并做它的工作：通知有關對象；任務又回到睡眠狀態(tài)。2022/8/1182確定優(yōu)先任務優(yōu)先任務可以滿足高優(yōu)先級或低優(yōu)先級的處理需求：高優(yōu)先級：某些服務具有很高的優(yōu)先級為了在嚴格限定的時間內完成這種服務，可能需要把這類服務分離成獨立

39、的任務。低優(yōu)先級：與高優(yōu)先級相反，有些服務是低優(yōu)先級的，屬于低優(yōu)先級處理(通常指那些背景處理)。設計時可能用額外的任務把這樣的處理分離出來。2022/8/1183確定關鍵任務關鍵任務是有關系統(tǒng)成功或失敗的關鍵處理，這類處理通常都有嚴格的可靠性要求。在設計過程中可能用額外的任務把這樣的關鍵處理分離出來，以滿足高可靠性處理的要求。對高可靠性處理應該精心設計和編碼，并且應該嚴格測試。2022/8/1184確定協(xié)調任務當系統(tǒng)中存在3個以上任務時，就應該增加一個任務，用它作為協(xié)調任務。優(yōu)劣：引入?yún)f(xié)調任務會增加系統(tǒng)的總開銷(增加從一個任務到另一個任務的轉換時間)引入?yún)f(xié)調任務有助于把不同任務之間的協(xié)調控制封

40、裝起來。方法：使用狀態(tài)轉換矩陣可以比較方便地描述該任務的行為。注意：這類任務應該僅做協(xié)調工作，不要讓它再承擔其他服務工作。2022/8/1185盡量減少任務數(shù)必須仔細分析和選擇每個確實需要的任務。應該使系統(tǒng)中包含的任務數(shù)盡量少。設計多任務系統(tǒng)的主要問題是：設計者常常為了自己處理時的方便而輕率地定義過多的任務。這樣做加大了設計工作的技術復雜度，并使系統(tǒng)變得不易理解，從而加大了系統(tǒng)維護的難度。2022/8/1186估算CPU或其他固件的處理能力使用多處理器(即“多個處理器”)或固件，主要是為了滿足高性能的要求。設計者必須通過計算系統(tǒng)載荷(即每秒處理的業(yè)務數(shù)及處理一個業(yè)務所花費的時間)，來估算所需要

41、的CPU(或其他固件)的處理能力。2022/8/1187確定資源需求設計者應該綜合考慮各種因素，以決定哪些子系統(tǒng)用硬件實現(xiàn)，哪些子系統(tǒng)用軟件實現(xiàn)。下面兩個因素可能是使用硬件實現(xiàn)某些子系統(tǒng)的主要因素?，F(xiàn)有的硬件完全能滿足某些方面的需求，例如，買一塊浮點運算卡比用軟件實現(xiàn)浮點運算要容易得多。專用硬件比通用的CPU性能更高。例如，目前在信號處理系統(tǒng)中廣泛使用固件實現(xiàn)快速傅里葉變換。設計者在決定到底采用軟件還是硬件的時候，必須綜合權衡一致性、成本、性能等多種因素，還要考慮未來的可擴充性和可修改性。2022/8/1188主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)

42、設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/1189數(shù)據(jù)任務管理子系統(tǒng)的任務數(shù)據(jù)管理子系統(tǒng)是系統(tǒng)存儲或檢索對象的基本設施，它：建立在某種數(shù)據(jù)存儲管理系統(tǒng)之上隔離了數(shù)據(jù)存儲管理模式(文件、關系數(shù)據(jù)庫或面向對象數(shù)據(jù)庫)的影響2022/8/1190“設計數(shù)據(jù)管理子系統(tǒng)”主要內容選擇數(shù)據(jù)存儲管理模式設計數(shù)據(jù)管理子系統(tǒng)2022/8/1191數(shù)據(jù)存儲管理模式不同的數(shù)據(jù)存儲管理模式有不同的特點，適用范圍也不相同，設計者應該根據(jù)應用系統(tǒng)的特點選擇適用的模式：文件管理系統(tǒng)關系數(shù)據(jù)庫管理系統(tǒng)面向對象數(shù)據(jù)庫管理系統(tǒng)2022/8/1192文件管理系統(tǒng)文件管理系統(tǒng)是操作系統(tǒng)的一個組成

43、部分，使用它長期保存數(shù)據(jù)具有成本低和簡單等特點。但是，文件操作的級別低，為提供適當?shù)某橄蠹墑e還必須編寫額外的代碼。此外，不同操作系統(tǒng)的文件管理系統(tǒng)往往有明顯差異。2022/8/1193關系數(shù)據(jù)庫管理系統(tǒng)的主要優(yōu)點關系數(shù)據(jù)庫管理系統(tǒng)的理論基礎是關系代數(shù)，它不僅理論基礎堅實而且有下列一些主要優(yōu)點：提供了各種最基本的數(shù)據(jù)管理功能(例如，中斷恢復，多用戶共享，多應用共享，完整性，事務支持等)。為多種應用提供了一致的接口。標準化的語言(大多數(shù)商品化關系數(shù)據(jù)庫管理系統(tǒng)都使用SQL語言)。2022/8/1194關系數(shù)據(jù)庫管理系統(tǒng)的缺點關系數(shù)據(jù)庫管理系統(tǒng)有下述一些具體缺點：運行開銷大：即使只完成簡單的事務(例

44、如，只修改表中的一行)，也需要較長的時間。不能滿足高級應用的需求：關系數(shù)據(jù)庫管理系統(tǒng)很難用在數(shù)據(jù)類型豐富或操作不標準的應用中。與程序設計語言的連接不自然：SQL語言支持面向集合的操作，是一種非過程性語言；然而大多數(shù)程序設計語言本質上卻是過程性的，每次只能處理一個記錄。這些具體缺點限制了關系數(shù)據(jù)庫管理系統(tǒng)的普遍使用。2022/8/1195面向對象數(shù)據(jù)庫管理系統(tǒng)面向對象數(shù)據(jù)庫管理系統(tǒng)是一種新技術，主要有兩種設計途徑：擴展的關系數(shù)據(jù)庫管理系統(tǒng)在關系數(shù)據(jù)庫基礎上，增加抽象數(shù)據(jù)類型和繼承機制；還增加了創(chuàng)建及管理類和對象的通用服務。擴展的面向對象程序設計語言擴充了面向對象程序設計語言的語法和功能，增加了在

45、數(shù)據(jù)庫中存儲和管理對象的機制。開發(fā)人員可以用統(tǒng)一的面向對象觀點進行設計，不再需要區(qū)分存儲數(shù)據(jù)結構和程序數(shù)據(jù)結構(即生命期短暫的數(shù)據(jù))。2022/8/1196“對象”數(shù)據(jù)管理模式的實現(xiàn)目前，大多數(shù)“對象”數(shù)據(jù)管理模式都采用“復制對象”的方法：先保留對象值，然后在需要時創(chuàng)建該對象的一個副本。擴展的OO程序設計語言則擴充了這種機制，它支持“永久對象”方法：準確存儲對象（包括對象的內部標識在內），而不是僅僅存儲對象值。使用這種方法，當從存儲器中檢索出一個對象的時候，它就完全等同于原先存在的那個對象?！坝谰脤ο蟆狈椒ǎ瑸樵诙嘤脩舡h(huán)境中從對象服務器中共享對象奠定了基礎。2022/8/1197“設計數(shù)據(jù)管理

46、子系統(tǒng)”主要內容選擇數(shù)據(jù)存儲管理模式設計數(shù)據(jù)管理子系統(tǒng)2022/8/1198設計數(shù)據(jù)管理子系統(tǒng)的任務設計數(shù)據(jù)管理子系統(tǒng)，需要：設計數(shù)據(jù)格式設計相應的服務。2022/8/1199設計數(shù)據(jù)格式設計數(shù)據(jù)格式的方法與使用的數(shù)據(jù)存儲管理模式密切相關。與前述數(shù)據(jù)存儲管理模式（文件管理系統(tǒng)、關系數(shù)據(jù)庫管理系統(tǒng)、面向對象數(shù)據(jù)庫管理系統(tǒng)）相對應的設計方法有：文件系統(tǒng)關系數(shù)據(jù)庫管理系統(tǒng)面向對象數(shù)據(jù)庫管理系統(tǒng)2022/8/11100設計數(shù)據(jù)格式文件系統(tǒng)設計文件系統(tǒng)的方法：定義第一范式表：列出每個類的屬性表；把屬性表規(guī)范成第一范式，從而得到第一范式表的定義。為每個第一范式表定義一個文件。測量性能和需要的存儲容量。修改

47、原設計的第一范式，以滿足性能和存儲需求。必要時把泛化結構的屬性壓縮在單個文件中，以減少文件數(shù)量。必要時把某些屬性組合在一起，并用某種編碼值表示這些屬性，而不再分別使用獨立的域表示每個屬性。這樣做可以減少所需要的存儲空間，但是增加了處理時間。2022/8/11101設計數(shù)據(jù)格式關系數(shù)據(jù)庫管理系統(tǒng)設計關系數(shù)據(jù)庫管理系統(tǒng)方法：定義第三范式表：列出每個類的屬性表；把屬性表規(guī)范成第三范式，從而得出第三范式表的定義。為每個第三范式表定義一個數(shù)據(jù)庫表。測量性能和需要的存儲容量。修改先前設計的第三范式，以滿足性能和存儲需求。2022/8/11102設計數(shù)據(jù)格式面向對象數(shù)據(jù)庫管理系統(tǒng)設計面向對象數(shù)據(jù)庫管理系統(tǒng)方

48、法：擴展的關系數(shù)據(jù)庫途徑：使用與關系數(shù)據(jù)庫管理系統(tǒng)相同的方法。擴展的面向對象程序設計語言途徑：不需要規(guī)范化屬性的步驟，因為數(shù)據(jù)庫管理系統(tǒng)本身具有把對象值映射成存儲值的功能。2022/8/11103設計數(shù)據(jù)管理子系統(tǒng)的任務設計數(shù)據(jù)管理子系統(tǒng)，需要：設計數(shù)據(jù)格式設計相應的服務2022/8/11104如何存儲對象在一個需要存儲的類中，增加一個特殊的屬性和服務，用于完成存儲對象自身的工作。應該把為此目的增加的屬性和服務作為“隱含”的屬性和服務，即：無須在面向對象設計模型的屬性和服務層中顯式地表示它們；僅需在關于類與對象的文檔中描述它們。2022/8/11105上述“存儲對象”方法的好處這樣設計之后，對

49、象將知道怎樣存儲自己。用于“存儲自己”的屬性和服務，在問題域子系統(tǒng)和數(shù)據(jù)管理子系統(tǒng)之間構成一座必要的橋梁。利用多重繼承機制，可以在某個適當?shù)幕愔卸x這樣的屬性和服務，然后，如果某個類的對象需要長期存儲，該類就從基類中繼承這樣的屬性和服務。這樣可避免許多冗余。2022/8/11106例子ATM系統(tǒng)-1由圖可見：惟一的永久性數(shù)據(jù)存儲放在分行計算機中。因為必須保持數(shù)據(jù)的一致性和完整性，而且常常有多個并發(fā)事務同時訪問這些數(shù)據(jù)，因此，采用成熟的商品化關系數(shù)據(jù)庫管理系統(tǒng)存儲數(shù)據(jù)。應該把每個事務作為一個不可分割的批操作來處理，由事務封鎖賬戶直到該事務結束為止。2022/8/11107例子ATM系統(tǒng)-2在這

50、個例子中，需要存儲的對象主要是賬戶類的對象。賬戶類對象存儲的兩種方法每個對象自己保存自己。帳戶類對象在接到“存儲自己”的通知后，知道怎樣把自己存儲起來(需要增加一個屬性和一個服務來定義上述行為)。由數(shù)據(jù)管理子系統(tǒng)負責存儲對象。帳戶類對象在接到“存儲自己”的通知后，知道怎樣向數(shù)據(jù)管理子系統(tǒng)發(fā)送什么消息，以便由數(shù)據(jù)管理子系統(tǒng)把它的狀態(tài)保存起來，為此也需要增加屬性和服務來定義上述行為。使用這種方法的優(yōu)點，是無須修改問題域子系統(tǒng)。應該定義一個數(shù)據(jù)管理類ObjectServer，并聲明它的對象。這個類提供下列服務：通知對象保存自身或保存需長期存儲的對象的狀態(tài)。檢索已存儲的對象并使之“復活”。2022/8

51、/11108主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/11109在什么時候設計類中的服務OOA得到的對象模型，通常并不詳細描述類中的服務。OOD則是擴充、完善和細化面向對象分析模型的過程，設計類中的服務是OOD的一項重要工作內容。設計類中的服務包括以下活動：確定類中應有的服務設計實現(xiàn)服務的方法2022/8/11110“設計類中的服務”主要內容確定類中應有的服務設計實現(xiàn)服務的方法2022/8/11111確定類中應有的服務需要綜合考慮對象模型、動態(tài)模型和功能模型，才能確定類中應

52、有的服務。對象模型是進行對象設計的基本框架。但是面向對象分析得出的對象模型，通常只在每個類中列出幾個最核心的服務。設計者必須把動態(tài)模型中對象的行為以及功能模型中的數(shù)據(jù)處理轉換成由適當?shù)念愃峁┑姆铡?022/8/11112狀態(tài)圖(或動態(tài)模型)的作用一張狀態(tài)圖描繪了一類對象的生命周期，圖中的狀態(tài)轉換是執(zhí)行對象服務的結果。對象的許多服務都與對象接收到的事件密切相關事實上，事件就表現(xiàn)為消息接收消息的對象必然有由消息選擇符指定的服務，該服務改變對象狀態(tài)(修改相應的屬性值)，并完成對象應做的動作。對象的動作既與事件有關，也與對象的狀態(tài)有關。如果一個對象在不同狀態(tài)可以接受同樣事件，而且在不同狀態(tài)接收到同

53、樣事件時其行為不同，則實現(xiàn)服務的算法中需要有一個依賴于狀態(tài)的DO_CASE型控制結構。2022/8/11113功能模型的作用功能模型中的數(shù)據(jù)處理，轉換成由適當?shù)念愃峁┑姆铡９δ苣Ｐ椭该髁讼到y(tǒng)必須提供的服務。狀態(tài)圖中狀態(tài)轉換所觸發(fā)的動作，在功能模型中有時可能擴展成一張數(shù)據(jù)流圖。2022/8/11114功能模型的作用數(shù)據(jù)流圖中的某些處理可能與對象提供的服務相對應，應該在該對象所屬的類中定義這個服務下列規(guī)則有助于確定這種定義：如果某個處理的功能是從輸入流中抽取一個值，則該輸入流就是目標對象。如果某個處理具有類型相同的輸入流和輸出流，而且輸出流實質上是輸入流的另一個形式，則該輸入輸出流就是目標對象

54、。如果某個處理從多個輸入流得出輸出值，則該處理是輸出類中定義的一個服務。如果某個處理把對輸入流處理的結果輸出給數(shù)據(jù)存儲或動作對象，則該數(shù)據(jù)存儲或動作對象就是目標對象。2022/8/11115如何確定處理的歸屬當一個處理涉及多個對象時，為確定把它作為哪個對象的服務，設計者必須判斷哪個對象在這個處理中起主要作用。通常在起主要作用的對象類中定義這個服務。下面兩條規(guī)則有助于確定處理的歸屬：如果處理影響或修改了一個對象，則最好把該處理與處理的目標（而不是觸發(fā)者）聯(lián)系在一起?？疾焯幚砩婕暗膶ο箢惣斑@些類之間的關聯(lián)，從中找出處于中心地位的類。如果其他類和關聯(lián)圍繞這個中心類構成星型，則這個中心類就是處理的目標

55、。2022/8/11116“設計類中的服務”主要內容確定類中應有的服務設計實現(xiàn)服務的方法2022/8/11117設計實現(xiàn)服務的方法1設計實現(xiàn)服務的算法時，應該考慮下列幾個因素：算法復雜度。 通常選用復雜度較低(即效率較高)的算法，但也不要過分追求高效率，應以能滿足用戶需求為準。容易理解與容易實現(xiàn)。容易理解與容易實現(xiàn)的要求往往與高效率有矛盾，設計者應該對這兩個因素適當折衷。易修改。應該盡可能預測將來可能做的修改，并在設計時預先做些準備。2022/8/11118設計實現(xiàn)服務的方法22. 選擇數(shù)據(jù)結構在分析階段，僅需考慮系統(tǒng)中需要的信息的邏輯結構；在OOD過程中，需要選擇能夠方便、有效地實現(xiàn)算法的物

56、理數(shù)據(jù)結構。3. 定義內部類和內部操作在OOD過程中，可能需要新增加一些在需求陳述中沒有提到的類，這些新類主要用來存放在執(zhí)行算法過程中所得出的某些中間結果。復雜操作往往可以用簡單對象上的更低層操作來定義。因此，在分解高層操作時常常引入新的低層操作。在面向對象設計過程中應該定義這些新增加的低層操作。2022/8/11119主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/11120關聯(lián)的重要性在對象模型中，關聯(lián)是聯(lián)結不同對象的紐帶，它指定了對象相互間的訪問路徑。在OOD過程中，設計人

57、員必須確定實現(xiàn)關聯(lián)的具體策略。既可選定一個全局性的策略統(tǒng)一實現(xiàn)所有關聯(lián)，也可以分別為每個關聯(lián)選擇具體的實現(xiàn)策略，以與它在應用系統(tǒng)中的使用方式相適應。為了更好地設計實現(xiàn)關聯(lián)的途徑，首先應該分析使用關聯(lián)的方式。2022/8/11121設計關聯(lián)中要討論的內容關聯(lián)的遍歷實現(xiàn)單向關聯(lián)實現(xiàn)雙向關聯(lián)關聯(lián)對象的實現(xiàn)2022/8/11122設計關聯(lián)之一：關聯(lián)的遍歷在應用系統(tǒng)中，使用關聯(lián)有兩種可能的方式：單向遍歷。某些關聯(lián)只需要單向遍歷，這種單向遍歷實現(xiàn)起來比較簡單。雙向遍歷。某些關聯(lián)可能需要雙向遍歷，雙向關聯(lián)實現(xiàn)起來稍微麻煩一些。在使用原型法開發(fā)軟件的時候，原型中所有關聯(lián)都應該是雙向的，以便于增加新的行為，快速

58、地擴充和修改原型。2022/8/11123設計關聯(lián)之二：實現(xiàn)單向關聯(lián)用指針可以方便地實現(xiàn)單向關聯(lián)。如果關聯(lián)的重數(shù)是一元的，則實現(xiàn)關聯(lián)的指針是一個簡單指針；如果重數(shù)是多元的，則需要用一個指針集合實現(xiàn)關聯(lián)。 2022/8/11124設計關聯(lián)之三：實現(xiàn)雙向關聯(lián)實現(xiàn)雙向關聯(lián)有下列3種方法：只用屬性實現(xiàn)一個方向的關聯(lián)，當需要反向遍歷時就執(zhí)行一次正向查找。如果兩個方向遍歷的頻度相差很大，而且需要盡量減少存儲開銷和修改時的開銷，則這是一種很有效的實現(xiàn)雙向關聯(lián)的方法。兩個方向的關聯(lián)都用屬性實現(xiàn)。這種方法能實現(xiàn)快速訪問，但是，如果修改了一個屬性，則相關的屬性也必須隨之修改，才能保持該關聯(lián)鏈的一致性。用獨立的關聯(lián)

59、對象實現(xiàn)雙向關聯(lián)。關聯(lián)對象不屬于相互關聯(lián)的任何一個類，它是獨立的關聯(lián)類的實例，如圖所示。2022/8/11125設計關聯(lián)之四：關聯(lián)對象的實現(xiàn)可以引入一個關聯(lián)類來保存描述關聯(lián)性質的信息，關聯(lián)中的每個連接對應著關聯(lián)類的一個對象。實現(xiàn)關聯(lián)對象的方法取決于關聯(lián)的重數(shù)。對于一對一關聯(lián)來說，關聯(lián)對象可以與參與關聯(lián)的任一個對象合并。對于一對多關聯(lián)來說，關聯(lián)對象可以與“多”端對象合并。如果是多對多關聯(lián)，則關聯(lián)鏈的性質不可能只與一個參與關聯(lián)的對象有關，通常用一個獨立的關聯(lián)類來保存描述關聯(lián)性質的信息，這個類的每個實例表示一條具體的關聯(lián)鏈及該鏈的屬性。2022/8/11126主要內容面向對象設計的準則啟發(fā)規(guī)則軟件重

60、用系統(tǒng)分解設計問題域子系統(tǒng)設計人機交互子系統(tǒng)設計任務管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計類中的服務設計關聯(lián)設計優(yōu)化2022/8/11127“設計優(yōu)化”主要內容確定優(yōu)先級提高效率的幾項技術調整繼承關系2022/8/11128確定優(yōu)先級時要有折衷方案系統(tǒng)的各項質量指標并不是同等重要的，設計人員必須確定各項質量指標的相對重要性(即確定優(yōu)先級)，以便在優(yōu)化設計時制定折衷方案。系統(tǒng)的整體質量與設計人員所制定的折衷方案密切相關。最終產(chǎn)品成功與否，在很大程度上取決于是否選擇好了系統(tǒng)目標。最糟糕的情況是，沒有站在全局高度正確確定各項質量指標的優(yōu)先級，以致系統(tǒng)中各個子系統(tǒng)按照相互對立的目標做了優(yōu)化，這將導致系統(tǒng)資源