9.1軟件維護的概念

9.2軟件維護的特點

9.3軟件維護的類型及比例

9.4區分維護類型的原則

9.5軟件維護的步驟

9.6軟件的可維護性

9.7軟件維護的副作用

9.8軟件重用9.1軟件維護的概念軟件維護是指軟件系統交付使用以后，為了改正軟件錯誤或滿足用戶新的需要而修改軟件的過程。在整個軟件生存周期中，軟件維護是最費時，也是最重要的一個階段。據有關資料統計，軟件維護占軟件總的開發工作量的60%以上，而維護費用可能占開發費用的55%～70%。因此，對軟件維護工作必須給予足夠的重視。軟件維護的作用如下：(1)在運行中發現軟件錯誤和設計缺陷，這些錯誤和缺陷在測試階段未能發現；改進設計，以便增強軟件的功能，提高軟件的性能。(2)要求已經運行的軟件能夠適應特定的硬件、軟件、外部設備、通信設備等的工作環境，或者是要求適應已變動的數據或文件。(3)使已經投入運行的軟件與其他相關的程序有良好的接口，以利于協同工作。(4)使運行軟件的應用范圍得到必要的擴充等。9.2軟件維護的特點1.結構化維護與非結構化維護軟件的開發過程對軟件的維護有較大的影響。根據軟件開發的過程可以把軟件維護分為結構化維護和非結構化維護兩類，如圖9.1所示。1)非結構化維護對于非結構化維護，軟件配置的唯一成分是程序代碼，沒有文檔。維護活動從艱苦地評價程序代碼開始，常常由于程序內部文檔不足而使評價更困難，對于軟件結構、全程數據結構、系統接口、性能和(或)設計約束等經常會產生誤解。因為沒有測試方面的文檔，所以不可能進行回歸測試。2)結構化維護對于結構化維護，軟件配置完整，維護工作從評價設計文檔開始，確定軟件重要的結構特點、性能特點以及接口特點；估計要求的改動將帶來的影響，并且計劃實施途徑。然后首先修改設計并且對所做的修改進行仔細復查。接下來編寫相應的源程序代碼；使用在測試說明書中包含的信息進行回歸測試。最后，把修改后的軟件再次交付使用。2.軟件的維護成本在過去的幾十年中，軟件維護的費用穩步上升。1970年用于維護已有軟件的費用只占軟件總預算的35%～40%，1980年上升為40%～60%，1990年上升為70%～80%。有形的維護費用只不過是軟件維護的最明顯的代價，其他一些現在還不明顯的代價將來可能更為人們所關注。因為可用的資源必須供維護任務使用，以致耽誤甚至喪失了開發的良機，這是一個無形的代價。其他無形的代價(維護成本)還有：(1)一些看起來是合理的改錯或修改的要求不能及時滿足，使得用戶不滿意；(2)維護時產生的改動，可能會帶來新的潛伏的故障，從而降低軟件的整體質量；(3)當必須把軟件開發人員抽調去進行維護工作時，將在開發過程中造成混亂。軟件維護的最后一個代價是生產率的大幅度下降，這種情況在維護舊程序時常常遇到。維護工作量可以分成生產性活動和非生產性活動。維護工作量的計算表達式如下：其中：M——維護中消耗的總工作量；P——生產性工作量； K——經驗常數； c——復雜程度(非結構化設計和缺少文檔都會增加軟件的復雜程度)； d——維護人員對軟件的熟悉程度。通過這個模型可以看出，如果使用了不好的軟件開發方法(沒有使用軟件工程方法論)，而且參加維護的人員都不是原來開發的人員，那么維護工作量(及成本)將按指數級增加。此外，還涉及以下成本的附加因素：(1)到用戶處的差旅費；(2)對維護者以及用戶的培訓費；(3)軟件工程環境和軟件測試環境的成本和年度維護費；(4)薪水和津貼之類的人員成本。建立維護概念時，要根據有限的可用數據估算成本。隨著開發工作的推進，估算要進一步細化，歷史度量數據應用作估算維護成本的輸入。3.軟件維護工具控制軟件維護成本的潛在方法是使用CASE工具，這些工具輔助軟件維護活動。CASE可以看成是一套相互關聯的、支持軟件開發和維護所有各方面的工具。這些相互關聯的CASE工具最好以軟件工程環境的形式匯集在一起，以支持那些支持軟件維護活動的方法、策略、指南及標準。最好也為維護者提供軟件測試環境，以便修改后的軟件產品能在非運行環境中測試。軟件工程環境提供初始開發和修改軟件產品的工具。軟件測試環境提供測試環境，應用于在非運行環境中測試修改后的軟件產品。注明成功運用CASE工具的日期。維護者應仔細策劃這些工作。4.軟件維護中的問題與軟件維護有關的絕大多數問題，都可歸因于軟件定義和軟件開發的方法有缺點。在軟件生命周期的前兩個時期沒有嚴格而又科學的管理和規則，幾乎必然會導致在最后階段出現問題。下面列出和軟件維護有關的部分問題。(1)理解他人編寫的程序一般都有一定的困難性。(2)軟件配置的文檔嚴重不足甚至沒有，或者沒有合格的文檔。(3)當需要對軟件進行維護時，由于軟件人員經常流動，維護階段持續的時間又很長，因此一般不能指望由原來的開發人員來完成或提供對軟件的解釋。(4)絕大多數軟件在設計時沒有考慮到將來的修改問題。(5)追蹤軟件的建立過程非常困難，或根本做不到。(6)軟件維護可以說是一項毫無吸引力的工作。之所以形成這樣一種觀念，一方面是因為軟件維護工作量大，看不到什么“成果”，更主要的原因是因為維護工作難度大，又經常遭受挫折，且從事這項工作缺乏成就感。上述種種問題在現有的沒有采用軟件工程思想開發出來的軟件中，都或多或少地存在著。而軟件工程部分地解決了與維護有關的各種問題。9.3軟件維護的類型及比例根據軟件維護的不同原因，軟件維護可以分成改正性維護、適應性維護、完善性維護和預防性維護4種類型。1.改正性維護(Corrective)因為軟件測試不可能暴露出一個大型軟件系統所有潛藏的錯誤，所以必然會有第一項維護活動：在任何大型程序的使用期間，用戶在某些特定的使用環境下必然會發現這些潛藏的程序錯誤，并且把他們遇到的問題報告給維護人員。診斷和改正錯誤的過程稱為改正性維護。2.適應性維護(Adaptive)計算機科學技術領域的各個方面都在迅速進步，外部環境、數據環境可能發生變化；另一方面，應用軟件的使用壽命很容易超過10年，遠遠長于最初開發這個軟件時的運行環境的壽命。因此，適應性維護也就是為了和變化了的環境適當地配合而進行的修改軟件的活動，是既必要又經常的維護活動。3.完善性維護(Perfective)當一個軟件系統順利運行時，常常出現第3項維護活動：在使用軟件的過程中用戶往往提出增加新功能或修改已有功能的建議，還可能提出一般性的改進意見。為了滿足這類要求，需要進行完善性維護。這項維護活動通常占軟件維護工作的大部分。4.預防性維護(Preventive)當為了改進未來的可維護性和可靠性，或為了給未來的改進奠定更好的基礎而修改尚未引起問題的產品缺陷時，將出現第4項維護活動。這項維護活動通常稱為預防性維護，它被定義為“把今天的方法學應用到昨天的系統，以支持明天的需求”。5.維護類型的比例在維護階段的前期，改正性維護的工作量較大。隨著錯誤發現率急劇降低，并趨于穩定，就進入正常使用期。然而，由于改造的要求，適應性維護和完善性維護的工作量逐步增加，在這些維護過程中又會引入新的錯誤，從而加重了維護的工作量。實踐證明，在這4項維護活動中，完善性維護所占的比例最大，即大部分維護工作是改變和加強軟件，而不是糾錯。所以，維護并不一定是救火式的緊急維修，而可以是有計劃的一種再開發活動。統計事實證明，完善性維護活動約占整個維護工作的50%，改正性維護占20%，適應性維護占25%，其他維護活動只占5%左右，如圖9.2所示。應該注意，上述4類維護活動都必須應用于整個軟件配置，維護軟件文檔和維護軟件的可執行代碼是同樣重要的。從圖9.3中可看到，軟件維護活動的工作量占整個生存周期的70%以上，這是因為漫長的軟件運行過程中需要不斷對軟件進行修改，以滿足用戶的擴充要求，加強軟件功能、性能的維護活動以及適應新的環境要求，它們需要花費很多精力和時間，而且有時修改不正確，經常還會引入新的錯誤。同時，軟件維護技術不像開發技術那樣成熟、規范化，自然消耗工作量就比較多。9.4區分維護類型的原則維護的部分任務是確定用戶的請求是屬于缺陷改正，還是適應性或完善性修改。開發方通常必須免費更正軟件缺陷，用戶則要支付適應性或完善性軟件修改的費用。在實踐中，區分它們可能非常困難，以下是一些指導原則。(1)若系統不能按程序員的意圖工作，則這是一個程序錯誤，屬于產品缺陷。(2)若系統沒有實現陳述的需求，則這是另一類缺陷，屬于違背需求。(3)若用戶有未說明的期望，但系統并不支持，則這屬于灰色區域。在實踐中，說明所有需求是不現實的。因此，對于用戶的合理期望，應屬于產品缺陷問題。(4)若問題不屬于開發時的合理期望，那么它是一項適應性或完善性修改。(5)若系統能夠完成用戶任務，但用戶想不出該如何執行，則這屬于可用性問題。它通常不作為產品缺陷，除非指定了可用性需求。由此可見，在維護問題上存在灰色區域，這些灰色區域可能引發爭執。為避免發生這種情況，合同可以包含這樣一項聲明：關于缺陷的爭執應交由雙方共同提出的仲裁者仲裁。9.5軟件維護的步驟9.5.1填寫維護申請報告所有軟件維護申請應按規定的方式提出。軟件維護組織通常提供維護申請報告(MRF，MaintenanceRequestForm)，或稱軟件問題報告(見表9.1)，由申請維護的用戶填寫。

如果遇到一個錯誤，則用戶必須完整地說明產生錯誤的情況，包括輸入數據、錯誤清單以及其他有關材料。如果申請的是適應性維護或完善性維護，則用戶必須提出一份修改說明書，列出所有希望的修改。維護申請報告將由維護管理員和系統監督員來研究處理。維護申請報告是由軟件組織外部提交的文檔，它是計劃維護工作的基礎。軟件組織內部應相應地做出軟件修改報告(Software

Change

Report，SCR)，報告中應指明：(1)所需修改變動的性質；(2)申請修改的優先級；(3)為滿足某個維護申請報告所需的工作量；(4)預計修改后的狀況。

軟件修改報告應提交修改負責人，經批準后才能開始進一步安排維護工作。9.5.2維護計劃維護計劃在軟件開發期間由維護者制訂，宜包含用戶如何提出更改軟件產品的請求。維護計劃應包含：(1)為何需要維護；(2)由誰做什么工作；(3)所參與的每個人的角色和職責是什么；(4)工作如何執行；(5)可用于維護的資源是什么；(6)維護在何處執行；(7)維護何時開始。9.5.3維護工作實施對于一項具體的軟件維護任務，在維護工作開始之前，應該建立一個維護小組，接著制訂維護的報告，并且為這項維護任務建立事件流模型，在維護完成后要保存維護的記錄，最后還應當評價本次維護活動。維護小組由若干名維護人員組成，其中包括一名維護管理員和數名系統管理員。所有的維護請求由維護管理員經過分析后傳給系統管理員去完成。系統管理員是熟悉軟件某一部分的軟件技術人員。所有的維護必須在修改批準人員允許的范圍內進行。維護小組的組成如圖9.4所示。在維護過程中，維護人員要各司其職，明確維護責任，以減少維護過程中的混亂。軟件維護所需要的一種報告是維護請求表。這是由軟件開發人員提供，由軟件用戶填寫的表格。如果軟件運行遇到問題，則用戶必須詳細描述出錯時的情況，包括輸入數據、輸出數據和其他有關資料。維護請求表是制訂軟件維護計劃的依據。在維護小組內部還應該指定一個軟件修改報告，內容包括：本次維護所需要的工作量、維護的性質、維護的優先級等。在制訂維護計劃之前，軟件修改報告要交給修改批準人進行審查。上述工作完成后，就可以為維護活動建立事件流模型了。圖9.5表示從提出維護請求到維護結束所出現的事件流。首先要判斷維護請求的類型。在這點上用戶和維護人員可能有不同的看法，用戶可能認為這次維護是改正性維護，而維護人員可能更愿意把它看成是適應性維護或完善性維護。對于這些不同意見，雙方必須協商解決。如果是改正性維護，那么接著要判斷錯誤的嚴重程度，如果屬于嚴重錯誤，系統的一部分無法運行，則維護管理員應該立即對問題進行分析，并分配人員進行維護。如果問題不嚴重，則這次維護和其他軟件開發任務放在一起，統一安排時間進行。對于完善性維護和適應性維護，可以當作同一性質的維護。首先判斷維護要求的優先級，如果優先級不高，則可以同其他開發任務放在一起，統一安排時間進行；否則，維護管理員應立即對問題進行分析，并分配人員進行維護。無論是什么性質的維護，當分配具體的系統管理員實施時，所需要的工作是大致相同的，包括復查軟件設計、修改代碼、單元測試、整體測試、有效性測試、系統測試和復審。就其本質而言，維護工作就相當于一次開發，因為在開發階段用到的文檔、開發方法，這里都會重新用到。在軟件維護事件流中的最后一步是復審，它再次驗證軟件的所有成分是否有效，是否滿足用戶在維護請求表中所提的要求。維護工作完成后，就該保存維護記錄。如果沒有維護記錄，就無法評價一個軟件使用的完好程度，也無法評價維護工作的有效性，難以估計維護的實際代價。維護記錄一般包括以下信息：(1)程序標識。(2)源程序代碼的行數。(3)機器代碼的數目。(4)編碼使用的程序設計語言。(5)程序完成的日期。(6)自從交付使用以來程序運行的次數。(7)自從交付使用以來程序出現故障的次數。(8)程序修改的次數和標識。(9)因程序修改而增加的源代碼數目。(10)因程序修改而刪除的源代碼數目。(11)每個修改所花費的人·時數。(12)程序修改的日期。(13)軟件工程師的名字。(14)維護請求表的標識。(15)維護類型。(16)維護開始和結束的日期。(17)用于完成維護任務所耗費的人·時數。(18)與維護有關的純利潤。如果在維護過程中記錄了以上數據，就可以對維護活動進行定量評價，可以從以下幾個方面度量維護活動：(1)每次程序運行時平均出現的故障數。(2)花費在每一種維護類型上的總工作量。(3)對每個程序、每種編程語言、每種維護類型平均進行的程序修改數。(4)增加或刪除一條源代碼所花費的工作量。(5)維護各種編程語言的源程序所花費的工作量。(6)處理一張維護請求表的平均時間。(7)各種維護請求類型所占的比例。根據對維護活動所進行的度量結果，可以幫助軟件開發人員重新做出關于開發技術、編程語言選擇、資源分配等方面的決定。9.5.4維護文檔整理在軟件維護活動進行的同時，需要記錄一些與維護工作有關的數據信息，這些信息可作為估計軟件維護的有效程度，確定軟件產品的質量，確定維護的實際開銷等工作的原始數據。其具體內容應包括：(1)程序標識符。(2)源語句數。(3)機器指令條數。(4)使用的程序設計語言。(5)程序安裝的日期。(6)自從安裝以來程序運行的次數。(7)自從安裝以來程序失效的次數。(8)程序變動的層次和標識。(9)因程序變動而增加的源語句數。(10)因程序變動而刪除的源語句數。(11)每個改動耗費的人·時數。(12)程序改動的日期。(13)軟件工程師的名字。(14)維護要求表的標識。(15)維護類型。(16)維護開始和完成的日期。(17)累計用于維護的人·時數。(18)與完成的維護相聯系的純效益。應該為每項維護工作都收集上述數據，以便填寫維護記錄表(見表9.2)。可以利用這些數據構成一個維護數據庫的基礎，并且用各種方法對它們進行評價。9.5.5維護活動評價如果已經開始進行維護活動，則可以對維護工作做一些定量的評價。至少可以從7個方面來度量維護工作。(1)每次程序允許平均失效的次數。(2)用于每一類維護活動的總人·時數。(3)平均每個程序、每種語言、每種維護類型所做的程序變動數。(4)維護過程中增加或刪除一個源語句平均花費的人·時數。(5)維護每種語言平均花費的人·時數。(6)一張維護表的平均周轉時間。(7)不同維護類型所占的百分比。根據對維護工作定量度量的結果，可以做出關于開發技術、語言選擇、維護工作量規劃、資源分配及其他許多方面的決定，而且可以利用這樣的數據去分析評價維護任務。9.6軟件的可維護性所謂軟件的可維護性，就是維護人員理解、掌握和修改被維護軟件的難易程度。具有可維護性的軟件，應具備如表9.3所示的4條性質。符合上述4個條件的軟件其可維護性很好，反之，可維護性就差。由此可知，可維護性與開發人員的素質關系極大。低素質的開發人員開發出低質量的軟件，其可維護性差，維護難度系數大，市場潛力就會十分渺茫。1.決定軟件可維護性的因素決定軟件可維護性的因素有：(1)可理解性：軟件的可理解性表現為人們通過閱讀源程序代碼和相關文檔，了解程序的結構、功能及使用的容易程度。一個可理解性好的程序應具備的特性有：模塊化、編碼風格一致，不使用令人捉摸不定或含糊不清的代碼，使用有意義的數據名和過程名，結構化，具有完整性等。(2)可靠性：表明一個程序按照用戶的要求和設計目標在給定的一段時間內正確執行的概率。關于可靠性，度量的標準主要有：①平均失效間隔時間(MITF)。②平均修復時間(MTTR)。③有效：A?=?MTBD(MTBD?+?MDT)，其中MTBD為系統平均不工作間隔時間，MDT為平均不工作時間。(3)可測試性：診斷和測試系統的難易程度。(4)可修改性：可修改性表明程序容易修改的程度。一個可修改的程序應當是可理解的、通用的、靈活的、簡單的。其中，通用性是指程序適用于各種功能變化而無須修改。靈活性是指能夠容易地對程序進行修改。2.可維護性復審在軟件工程的每一個階段、每一項活動的復審環節中，應該著重對可維護性進行復審，盡可能提高可維護性，至少要保證不降低可維護性。9.7軟件維護的副作用所謂軟件維護的副作用，是指因修改軟件而造成的錯誤或其他不希望發生的情況。軟件維護的副作用主要有3種，即修改軟件源程序的副作用、修改數據的副作用和修改文檔資料的副作用。1.修改軟件源程序的副作用在使用程序設計語言修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序，刪除或修改一個標號，刪除或修改一個標識符，改變程序代碼的時序關系，改變占用存儲的大小，改變邏輯運算符，修改文件的打開或關閉，改進程序的執行效率，把設計的改變翻譯成代碼的改變，以及為邊界條件的邏輯測試做出改變時，都容易引入錯誤。2.修改數據的副作用在修改數據結構時，有可能造成軟件設計與數據結構不匹配，因而導致軟件出錯。修改數據的副作用就是修改軟件信息結構導致的結果。例如，在重新定義局部或全局常量，重新定義記錄或文件格式，增大或減小一個數組或高層數據結構的大小，修改全局或公共數據，重新初始化控制標志或指針，重新排列輸入／輸出或子程序的參數時，容易導致設計與數據不相容的錯誤。修改數據的副作用可以通過詳細的設計文檔加以控制。在此文檔中描述了一種交叉引用，把數據元素、記錄、文件和其他結構聯系起來。3.修改文檔資料的副作用對數據流、軟件結構、模塊邏輯或任何其他有關特性進行修改時，必須對相關技術文檔進行相應修改，否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤，使得軟件文檔不能反映軟件的當前狀態。對于用戶來說，軟件事實上就是文檔。如果對可執行軟件的修改不反映在文檔里，就會產生修改文檔的副作用。例如，對交互輸入的順序或格式進行的修改，如果沒有正確地記錄在文檔中，就可能引起重大的問題。過時的文檔內容、索引和文本可能造成沖突，引起用戶的失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。軟件維護的方式及其副作用的表現如表9.4所示。9.8軟件重用1.軟件重用的概念軟件重用是指在兩次或多次不同的軟件開發過程中重復使用相同或相似軟件元素的過程。軟件元素包括程序代碼、測試用例、設計文檔、設計過程、需求分析文檔甚至領域知識。對于新的軟件開發項目而言，它們或者是構成整個目標軟件系統的部件，或者在軟件開發過程中發揮某種作用。通常將這些軟件元素稱為軟部件。為了能夠在軟件開發過程中重用現有的軟部件，必須在此之前不斷地進行軟部件的積累，并將它們組織成軟部件庫。這就是說，軟件重用不僅要討論如何檢索所需的軟部件以及如何對它們進行必要的修剪，還要解決如何選取軟部件、如何組織軟部件庫等問題。因此，軟件重用方法學通常要求軟件開發項目既要考慮重用已有軟部件的機制，又要系統地考慮生產可重用軟部件的機制。這類項目通常被稱為軟件重用項目。2.軟件重用技術的意義軟件重用技術的意義有：(1)可以減少軟件開發過程中大量的重復性工作，提高軟件生產率，降低開發成本，縮短開發周期。(2)通過軟部件嚴格的質量認證，使采用軟件重用技術開發的軟件系統有更可靠的質量保證。(3)使用可重用軟部件有利于軟件系統的結構優化，提高軟件的靈活性和標準化程度。3.軟件重用的過程按照重要活動是否跨越相似性較小的多個應用領域，軟件重用可區別為橫向重用和縱向重用。橫向重用(horizontalreuse)是指重用不同應用領域中的軟件元素，如數據結構、分類算法、人機界面構件等。標準函數庫是一種典型的、原始的橫向重用機制。縱向重用是指在一類具有較多公共性的應用領域之間進行軟部件重用。因為在兩個截然不同的應用領域之間實施軟件重用的潛力不大，所以縱向重用才廣受矚目，并成為軟件重用技術的真正所在。不難理解，縱向重用活動的主要關鍵點即是域分析；根據應用領域的特征及相似性預測軟部件的可重用性。一旦根據域確認了軟部件的重用價值，即可進行軟部件的開發并對具有重用價值的軟部件進行一般化，以便它們能夠適應新的類似的應用領域。然后，軟部件及其文檔即可進入軟部件庫，成為可供后續開發項目使用的可重用資源。這些部件構成軟部件構造活動。顯然，它是一個軟部件不斷積累、不斷完善的漸進過程。隨著軟部件的不斷豐富，軟部件庫的規模會不斷擴大，因此，庫的組織結構將直接影響軟部件的檢索效應，特別是當檢索手段并不局限于標準函數庫所采用的簡單名字匹配方法時更是如此。可供候選的軟部件從庫中檢索出來以后，用戶還必須理解其功能及行為，以判別它是否真正適用于當前項目。必要時可考慮對某個與期望的功能/行為匹配程度最佳的軟部件進行稍許修改，甚至可以將修改后的軟部件加進軟部件庫以替代原有的軟部件。當然，這要求修改后的軟部件比原有軟部件具有更高的重用價值。上述軟件重用方法如圖9.6所示。顯然，軟件重用過程可借助計算機的幫助。支持軟件重用的CASE工具的主要任務是，用某種組織結構實現軟部件庫的存儲，提供友好的人機界面，幫助用戶瀏覽、檢索和修改軟部件庫，并且對用戶感興趣的問題進行解釋。事實上，現在幾乎所有的軟件重用活動都是在CASE工具的幫助下進行的。使用重用技術可以減少軟件開發活動中大量的重復性工作，這樣就能夠提高軟件的生產率，降低開發成本，縮短開發周期。同時，由于軟部件大都經過嚴格的質量認證，并在實際運行環境中得到檢驗，因此，重用軟部件有助于改善軟件質量。此外，大量使用軟部件后，軟件的靈活性和標準化程度也可望得到提高。10.1面向對象的概念

10.2面向對象的模型

10.3面向對象的分析

10.4面向對象的設計

10.5面向對象的實現

10.6面向對象和基于對象的區別10.1面向對象的概念面向對象(ObjectOriented，OO)是20世紀90年代以來主流的軟件開發方法。面向對象的概念和應用已超越了程序設計和軟件開發，擴展到很寬的范圍，如數據庫系統、交互式界面、應用結構、應用平臺、分布式系統、網絡管理結構、CAD技術、人工智能等領域。起初，“面向對象”是專指在程序設計中采用封裝、繼承、抽象等設計方法。可是，這個定義顯然不適合現在的情況。面向對象的思想已經涉及軟件開發的各個方面，如面向對象的分析(ObjectOrientedAnalysis，OOA)，面向對象的設計(ObjectOrientedDesign，OOD)以及面向對象的編程實現(ObjectOrientedProgramming，OOP)。10.1.1傳統開發方法存在的問題傳統開發方法存在以下幾個問題。1.軟件重用性差重用性是指同一事物不經修改或稍加修改就可多次重復使用的性質。傳統的程序設計通過庫函數的方式來實現重用，實踐表明標準函數庫缺乏靈活性，往往難以適應不同應用場合的不同要求。對于用戶自己設計的功能模塊，對它的重用也有限制，一方面要保證功能完全相同，否則需要進行修改，另一方面，過程和數據是相互依賴的，功能的變化往往涉及數據結構的改變，如果新的應用中的數據與原來模塊中的數據不同，則對數據進行修改的同時，功能模塊也需要修改。2.軟件可維護性差軟件工程強調軟件的可維護性，強調文檔資料的重要性，規定最終的軟件產品應該由完整、一致的配置成分組成。在軟件開發過程中，始終強調軟件的可讀性、可修改性和可測試性是軟件的重要的質量指標。實踐證明，用傳統方法開發出來的軟件，維護時其費用和成本仍然很高，其原因是可修改性差，維護困難，導致可維護性差。3.開發出的軟件不能滿足用戶需要用傳統的結構化方法開發大型軟件系統涉及各種不同領域的知識，在開發需求模糊或需求動態變化的系統時，所開發出的軟件系統往往不能真正滿足用戶的需要。用結構化方法開發的軟件，其穩定性、可修改性和可重用性都比較差，這是因為結構化方法的本質是功能分解，從代表目標系統整體功能的單個處理著手，自頂向下不斷把復雜的處理分解為子處理，這樣一層一層地分解下去，直到僅剩下若干個容易實現的子功能處理為止，然后用相應的工具來描述各個最底層的處理。因此，結構化方法是圍繞實現處理功能的“過程”來構造系統的。然而，用戶需求的變化大部分是針對功能的，因此，這種變化對于基于過程的設計來說是災難性的。用這種方法設計出來的系統結構常常是不穩定的，用戶需求的變化往往造成系統結構的較大變化，從而需要花費很大代價才能實現這種變化。10.1.2面向對象的基本概念1.對象對象是人們要進行研究的任何事物，它不僅能表示具體的事物，還能表示抽象的規則、計劃或事件。我們所指的對象是計算機中的對象，是對現實中對象的模擬，它抽象出現實世界中對象的特征和行為，分別用數據和函數刻畫，并封裝成一個整體。模擬后的計算機對象既能體現現實世界事物的狀態，也具有相應的行為。在不同領域中對于對象有不同理解。一般地認為，對象就是一種事物，一個實體。在面向對象的領域中，則應當從概念和實現形式兩個角度來理解對象。從概念上講，對象是代表著正在創建的系統中的一個實體。例如，一個商品銷售系統，像顧客、商品、柜臺、廠家等都是對象，這些對象對于實現系統的完整功能都是必要的。從實現形式上講，對象是一個狀態和操作(方法)的封裝體。狀態是由對象的數據結構的內容和值定義的，方法是一系列的實現步驟，它是由若干操作構成的。對象實現了信息隱藏，對象與外部是通過操作接口聯系的，方法的具體實現外部是不可見的。封裝的目的就是阻止非法的訪問，操作接口提供了這個對象的功能。對象是通過消息與另一個對象傳遞信息的，每當一個操作被調用時，就有一條消息被發送到這個對象上，消息帶來了將被執行的這個操作的詳細內容。一般地講，消息傳遞的語法隨系統不同而不同，其他組成部分包括：目標對象、所請求的方法和參數。2.對象的狀態和行為對象具有狀態，一個對象用數據值來描述它的狀態。對象還有操作，用于改變對象的狀態，對象及其操作就是對象的行為。對象實現了數據和操作的結合，使數據和操作封裝于對象的統一體中。3.類我們習慣上把具有相同或相似性質的對象劃分成類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。類是創建對象的樣板，它包含著所創建對象的狀態描述和方法的定義。類的完整描述包含了外部接口和內部算法以及數據結構的形式。由一個特定的類所創建的對象被稱為這個類的實例，因此類是對象的抽象及描述，它是具有共同行為的若干對象的統一描述體。類中要包含生成對象的具體方法。類是抽象數據類型的實現。一個類的所有對象都有相同的數據結構，并且共享相同的實現操作的代碼，而各個對象有著各自不同的狀態，即私有的存儲。因此，類是所有對象的共同的行為和不同狀態的集合體。類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。類具有操作，它是對象的行為的抽象，用操作名和實現該操作的方法來描述。4.類的結構在客觀世界中有若干類，這些類之間有一定的結構關系。通常有兩種主要的結構關系，即一般—具體結構關系，整體—部分結構關系。(1)一般—具體結構稱為分類結構，也可以說是“或”關系，或者是“isa”關系。(2)整體—部分結構稱為組裝結構，它們之間的關系是一種“與”關系，或者是“hasa”關系。5.消息和方法對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發送給某個對象時，消息包含接收對象去執行某種操作的信息。發送一條消息至少要包括說明接受消息的對象名、發送給該對象的消息名(即對象名、方法名)。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。類中操作的實現過程叫做方法，一個方法有方法名、參數和方法體。消息傳遞如圖10.1所示。10.1.3面向對象的特征(1)對象唯一性。每個對象都有自身唯一的標識，通過這種標識，可找到相應的對象。在對象的整個生命期中，它的標識都不改變，不同的對象不能有相同的標識。(2)分類性。分類性是指將具有一致的數據結構(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應用有關的重要性質，而忽略其他一些無關內容。任何類的劃分都是主觀的，但必須與具體的應用有關。(3)繼承性。繼承性是子類自動共享父類數據結構和方法的機制，這是類之間的一種關系。在定義和實現一個類的時候，可以在一個已經存在的類的基礎之上來進行，把這個已經存在的類所定義的內容作為自己的內容，并加入若干新的內容。繼承性是面向對象程序設計語言不同于其他語言的最重要的特點，是其他語言所沒有的。在類層次中，子類只繼承一個父類的數據結構和方法，則稱為單重繼承。在類層次中，子類繼承了多個父類的數據結構和方法，則稱為多重繼承。在軟件開發中，類的繼承性使所建立的軟件具有開放性、可擴充性，這是信息組織與分類的行之有效的方法，它簡化了對象、類的創建工作量，增加了代碼的可重性。采用繼承性，提供了類的規范的等級結構。通過類的繼承關系，使公共的特性能夠共享，提高了軟件的重用性。(4)多態性。多態性是指相同的操作或函數、過程可作用于多種類型的對象上并獲得不同的結果。不同的對象，收到同一消息可以產生不同的結果，這種現象稱為多態性。多態性允許每個對象以適合自身的方式去響應共同的消息。多態性增強了軟件的靈活性和重用性。10.1.4面向對象的要素面向對象的要素包括：(1)抽象。抽象是指強調實體的本質、內在的屬性。在系統開發中，抽象指的是在決定如何實現對象之前的對象的意義和行為。使用抽象可以盡可能避免過早考慮一些細節。類實現了對象的數據(即狀態)和行為的抽象。(2)封裝性(信息隱藏)。封裝性是保證軟件部件具有優良的模塊性的基礎。面向對象的類是封裝良好的模塊，類定義將其說明(用戶可見的外部接口)與實現(用戶不可見的內部實現)顯式地分開，其內部實現按其具體定義的作用域提供保護。對象是封裝的最基本單位。封裝防止了程序相互依賴性而帶來的變動影響。面向對象的封裝比傳統語言的封裝更為清晰、更為有力。(3)共享性。面向對象技術在不同級別上促進了共享同一類中的共享。同一類中的對象有著相同的數據結構。這些對象之間是結構、行為特征的共享關系。在同一應用中共享。在同一應用的類層次結構中，存在繼承關系的各相似子類中，存在數據結構和行為的繼承，使各相似子類共享共同的結構和行為。使用繼承來實現代碼的共享，這也是面向對象的主要優點之一。另一種共享是在不同應用中的共享。面向對象不僅允許在同一應用中共享信息，而且為未來目標的可重用設計準備了條件。通過類庫這種機制和結構來實現不同應用中的信息共享。(4)強調對象結構而不是程序結構。10.1.5面向對象的開發方法1.?Booch方法Booch最先描述了面向對象的軟件開發方法的基礎問題，指出面向對象開發是一種根本不同于傳統的功能分解的設計方法。面向對象的軟件分解更接近人對客觀事務的理解，而功能分解只通過問題空間的轉換來獲得。2.?Coad方法Coad方法是1989年Coad和Yourdon提出的面向對象開發方法。該方法的主要優點是通過多年來大系統開發的經驗與面向對象概念的有機結合，在對象、結構、屬性和操作的認定方面，提出了一套系統的原則。該方法完成了從需求角度進一步進行類和類層次結構的認定。盡管Coad方法沒有引入類和類層次結構的術語，但事實上已經在分類結構、屬性、操作、消息關聯等概念中體現了類和類層次結構的特征。3.?OMT方法OMT方法是1991年由JamesRumbaugh等5人提出來的，其經典著作為“面向對象的建模與設計”。該方法是一種新興的面向對象的開發方法，開發工作的基礎是對真實世界的對象建模，然后圍繞這些對象使用分析模型來進行獨立于語言的設計，面向對象的建模和設計促進了對需求的理解，有利于開發出更清晰、更容易維護的軟件系統。該方法為大多數應用領域的軟件開發提供了一種實際的、高效的保證，努力尋求一種問題求解的實際方法。4.?UML(UnifiedModelingLanguage)語言軟件工程領域在1995—1997年取得了前所未有的進展，其成果超過軟件工程領域過去15年的成就總和，其中最重要的成果之一就是統一建模語言(UML)的出現。UML將是面向對象技術領域內占主導地位的標準建模語言。UML不僅統一了Booch方法、OMT方法和OOSE(面向對象軟件工程)方法的表示方法，而且對其作了進一步的發展，最終統一為大眾接受的標準建模語言。UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言。它融入了軟件工程領域的新思想、新方法和新技術。它的作用域不限于支持面向對象的分析與設計，還支持從需求分析開始的軟件開發全過程。10.2面向對象的模型10.2.1對象模型對象模型表示了靜態的、結構化的系統數據性質，描述了系統的靜態結構，它是從客觀世界實體的對象關系角度來描述，表現了對象的相互關系。該模型主要關心系統中對象的結構、屬性和操作，它是分析階段3個模型的核心，是其他兩個模型的框架。1.對象和類對象和類涉及以下內容：(1)對象。對象建模的目的就是描述對象。(2)類。通過將對象抽象成類，可以使問題抽象化，抽象增強了模型的歸納能力。類的符號表示如圖10.2所示。(3)屬性。屬性指的是類中對象所具有的性質(數據值)。(4)操作和方法。操作是類中對象所使用的一種功能或變換。類中的各對象可以共享操作，每個操作都有一個目標對象作為其隱含參數。方法是類的操作的實現步驟。2.關聯關聯用于描述類與類之間的連接。由于對象是類的實例，因此，類與類之間的關聯也就是其對象之間的關聯。類與類之間有多種連接方式，每種連接的含義各不相同(語義的連接)，但外部表示形式相似，故統稱為關聯。關聯關系一般都是雙向的，即關聯的對象雙方彼此都能與對方通信。反過來說，如果某兩個類的對象之間存在可以互相通信的關系，或者說對象雙方能夠感知另一方，那么這兩個類之間就存在關聯關系。描述這種關系常用的字句是：“彼此知道”“互相連接”等。根據不同的含義，關聯可分為普通關聯、遞歸關聯、限定關聯、或關聯、有序關聯、三元關聯(見圖10.3)和聚合7種。比較常用的關聯有普通關聯、遞歸關聯和聚合。1)普通關聯普通關聯是最常見的一種關聯，只要類與類之間存在連接關系就可以用普通關聯表示。比如，作家使用計算機，計算機會將處理結果等信息返回給作家，那么，在其各自所對應的類之間就存在普通關聯關系。普通關聯的圖示是連接兩個類之間的直線，如圖10.4所示。2)遞歸關聯如果一個類與它本身有關聯關系，那么這種關聯稱為遞歸關聯。任何關聯關系中都涉及與此關聯有關的角色，也就是與此關聯相連的類中的對象所扮演的角色關聯中的角色通常用字符串命名。在類圖中，把角色的名字放置在與此角色有關的關聯關系(直線)的末端，并且緊挨著使用該角色的類。角色名是關聯的一個組成部分，建模者可根據需要選用。引入角色的好處是能夠指明類和類的對象之間的聯系。注意，角色名不是類的組成部分，一個類可以在不同的關聯中扮演不同的角色。3)聚合聚合是關聯的特例。如果類與類之間的關系具有“整體與部分”的特點，則把這樣的關聯稱為聚合。例如，汽車由車輪、發動機、底盤等構成，則表示汽車的類與表示輪子的類、發動機的類、底盤的類之間的關系就具有“整體與部分”的特點，因此，這是一個聚合關系。識別聚合關系的常用方法是尋找“由……構成”“包含”“是……的一部分”等字句，這些字句很好地反映了相關類之間的“整體-部分”關系。聚合的圖示方式為，在表示關聯關系的直線末端加一個空心的小菱形，空心菱形緊挨著具有整體性質的類，如圖10.8所示，聚合關系中可以出現重數、角色(僅用于表示部分的類)和限定詞，也可以給聚合關系命名，圖10.8所示的聚合關系表示海軍由許多軍艦組成。除去上述的一般聚合外，聚合還有兩種特殊的聚合方式，即共享聚合和復合聚合。如果聚合關系中的處于部分方的對象同時參與了多個處于整體方對象的構成，則該聚合稱為共享聚合。比如，一個球隊(整體方)由多個球員(部分方)組成，但是一個球員還可能加入了多個球隊，球隊和球員之間的這種關系就是共享聚合。共享聚合關系可以通過聚合的重數反映出來，如果作為整體方的類的重數不是1，那么該聚合就是共享聚合，如圖10.9所示。如果構成整體類的部分類，完全隸屬于整體類，則這樣的聚合稱為復合聚合。換句話說，如果沒有整體類，則部分類也沒有存在的價值，部分類的存在是因為有整體類的存在。比如，窗口由文本框、列表框、按鈕和菜單組成。整體方的重數必須是零或1，部分方的重數可取任意范圍值，如圖10.10所示。3.繼承一個類的所有信息(屬性或操作)能被另一個類繼承，繼承某個類的子類中不僅可以有屬于自己的信息，而且還擁有了被繼承類中的信息。引入繼承的好處在于由于把一般的公共信息放在父類中，因此處理某個具體特殊情況時只需要定義該情況的個別信息，公共信息從父類中繼承得來，增強了系統的靈活性、易維護性和可擴充性。程序員只要定義新擴充或更改的信息就可以了，舊的信息完全不必修改(仍可繼續使用)，大大縮短了維護系統的時間。繼承某類所有信息的具體類，稱為子類，被繼承類稱為父類。可以從父類中繼承的信息有屬性、操作和所有的關聯關系。建模過程如下：(1)識別繼承關系。確定了類中應該定義的屬性之后，就可以利用繼承機制共享公共性質，并對系統中眾多的類加以組織。繼承關系的建立實質上是知識抽取的過程，它應該反映出一定深度的領域知識，因此必須有領域專家密切配合才能完成。許多歸納關系都是根據客觀世界現有的分類模式建立起來的，只要可能，就應該使用現有的概念。一般說來，可以使用以下兩種方式建立繼承(即歸納)關系。①自底向上：抽象出現有類的共同性質泛化出父類，這個過程實質上模擬人類歸納思維過程。②自頂向下：把現有類細化成更具體的子類，這模擬了人類的演繹思維過程。從應用域中常常能明顯看出應該做的自頂向下的具體化工作。例如，帶有形容詞修飾的名詞詞組往往暗示了一些具體類。但是，在分析階段應該避免過度細化。使用多重繼承機制時，通常應該指定一個主要父類，從它繼承大部分屬性和行為；次要父類只補充一些屬性和行為。(2)反復修改。在實際的建模過程中，僅僅經過一次建模過程很難得到完全正確的對象模型。事實上，軟件建模過程本身就是一個反復修改、逐步完善的過程。在建模的任何一個步驟中，如果發現了模型的缺陷，都必須返回到前期階段進行修改。由于面向對象的概念和符號在整個開發過程中都是一致的，因此更容易實現反復修改及逐步完善的過程。4.對象模型對象模型由一個或若干個模板組成。模板將模型分為若干個便于管理的子塊，在整個對象模型和類及關聯的構造塊之間，模板提供了一種集成的中間單元，模板中的類名及關聯名是唯一的。10.2.2動態模型動態模型是與時間和變化有關的系統性質。該模型描述了系統的控制結構，它表示了瞬間的、行為化的系統控制性質，它關心的是系統的控制，操作的執行順序，它表示從對象的事件和狀態的角度出發，表現了對象的相互行為。該模型描述的系統屬性是觸發事件、事件序列、狀態、事件與狀態的組織。使用狀態圖作為描述工具。它涉及事件、狀態、操作等重要概念。1.事件事件是指定時刻發生的某件事。2.狀態狀態是對象屬性值的抽象。對象的屬性值按照影響對象顯著行為的性質將其歸并到一個狀態中去。狀態指明了對象對輸入事件的響應。3.狀態圖狀態圖用來描述一個特定對象的所有可能狀態及其引起狀態轉移的事件。大多數面向對象技術都用狀態圖表示單個對象在其生命周期中的行為。一個狀態圖包括一系列的狀態以及狀態之間的轉移。10.2.3功能模型功能模型描述了系統的所有計算。功能模型指出發生了什么，動態模型確定什么時候發生，而對象模型確定發生的客體。功能模型表明一個計算如何從輸入值得到輸出值，它不考慮計算的次序。功能模型由多張數據流圖組成。數據流圖用來表示從源對象到目標對象的數據值的流向，它不包含控制信息，控制信息在動態模型中表示，同時數據流圖也不表示對象中值的組織，值的組織在對象模型中表示。數據流圖中包含有處理、數據流、動作對象和數據存儲對象。(1)處理。數據流圖中的處理用來改變數據值。最低層處理是純粹的函數，一張完整的數據流圖是一個高層處理。(2)數據流。數據流圖中的數據流將對象的輸出與處理、處理與對象的輸入、處理與處理聯系起來。在一個計算機中，用數據流來表示中間數據值，數據流不能改變數據值。(3)動作對象。動作對象是一種主動對象，它通過生成或者使用數據值來驅動數據流圖。(4)數據存儲對象。數據流圖中的數據存儲是被動對象，它用來存儲數據。它與動作對象不一樣，數據存儲本身不產生任何操作，它只響應存儲和訪問的要求。10.3面向對象的分析面向對象分析的目的是對客觀世界的系統進行建模。以上面介紹的模型概念為基礎，結合“銀行網絡系統”的具體實例來構造客觀世界問題的準確、嚴密的分析模型。分析模型有3種用途：用來明確問題需求；為用戶和開發人員提供明確需求；為用戶和開發人員提供一個協商的基礎，作為后繼的設計和實現的框架。10.3.1面向對象的分析過程面向對象的分析過程如圖10.15所示。系統分析的第一步是：陳述需求。分析者必須同用戶一起工作來提煉需求，因為這樣才表示了用戶的真實意圖，其中涉及對需求的分析及查找丟失的信息。下面以“銀行網絡系統”為例，用面向對象方法進行開發。銀行網絡系統問題陳述：設計一個支持銀行ATM計算機網絡系統的軟件。這個網絡包括柜員機和自動取款機(ATM)，由聯營機構共享。每個營業部提供各自的計算機來維護它的賬戶和處理面臨的事務。柜員機屬于各營業部，并且直接與營業部計算機通信，柜員輸入賬務和處理數據。ATM與中心處理機通信。中心處理機分理事務到相應的營業部。ATM接收現金卡，與用戶交互，與中心計算機通信完成事務處理，分配現金和打印收據。系統需要恰當的記錄和安全保證。系統必須正確控制并發訪問同一賬號。營業部提供自己的計算機軟件。共享系統的費用由各營業部根據現金卡數量來分擔。圖10.16給出銀行網絡系統的示意圖。10.3.2建立對象模型首先標識和關聯，因為它們影響了整體結構和解決問題的方法；其次是增加屬性，進一步描述類和關聯的基本網絡，使用繼承合并和組織類；最后操作增加到類中去作為構造動態模型和功能模型的副產品。1.確定類構造對象模型的第一步是標出來自問題域的相關的對象類，對象包括物理實體和概念。所有類在應用中都必須有意義，在問題陳述中，并非所有類都是明顯給出的。有些是隱含在問題域或一般知識中的。按圖10.17所示的過程確定類。查找問題陳述中的所有名詞，產生暫定類。根據下列標準，去掉不必要的類和不正確的類。(1)冗余類：若兩個類表述了同一個信息，則保留最富有描述能力的類。(2)不相干的類：除掉與問題沒有關系或根本無關的類。(3)模糊類：類必須是確定的，有些暫定類邊界定義模糊或范圍太廣。(4)屬性：如果某些名詞描述的是其他對象的屬性，則從暫定類中刪除。如果某一性質的獨立性很重要，就應該把它歸屬到類，而不把它作為屬性。(5)操作：如果問題陳述中的名詞有動作含義，則描述的操作就不是類。但是具有自身性質而且需要獨立存在的操作應該描述成類。2.準備數據字典為所有建模實體準備一個數據字典。準確描述各個類的精確含義，描述當前問題中的類的范圍，包括對類的成員、用法方面的假設或限制。3.確定關聯兩個或多個類之間的相互依賴就是關聯。一種依賴表示一種關聯，可用各種方式來實現關聯，但在分析模型中應刪除實現的考慮，以便設計時更為靈活。關聯常用描述性動詞或動詞詞組來表示，其中有物理位置的表示、傳導的動作、通信、所有者關系、條件的滿足等。從問題陳述中抽取所有可能的關聯表述，把它們記下來，但不要過早去細化這些表述。所有可能的關聯，大多數是直接抽取問題中的動詞詞組而得到的。在陳述中，有些動詞詞組表述的關聯是不明顯的。最后，還有一些關聯與客觀世界或人的假設有關，必須同用戶一起核實這種關聯，因為這種關聯在問題陳述中找不到。使用下列標準去掉不必要和不正確的關聯：(1)若某個類已被刪除，那么與它有關的關聯也必須刪除或者用其他類來重新表述。(2)不相干的關聯或實現階段的關聯：刪除所有問題域之外的關聯或涉及實現結構中的關聯。(3)動作：關聯應該描述應用域的結構性質而不是瞬時事件。(4)派生關聯：省略那些可以用其他關聯來定義的關聯。因為這種關聯是冗余的。4.確定屬性屬性是個體對象的性質，屬性通常用修飾性的名詞詞組來表示。形容詞常常表示具體的可枚舉的屬性值，屬性不可能在問題陳述中完全表述出來，必須借助于應用域的知識及對客觀世界的知識才可以找到它們。只考慮與具體應用直接相關的屬性，不要考慮那些超出問題范圍的屬性。首先找出重要屬性，避免那些只用于實現的屬性，要為各個屬性取有意義的名字。按下列標準刪除不必要的和不正確的屬性：(1)對象：若實體的獨立存在比它的值重要，那么這個實體不是屬性而是對象。(2)限定詞：若屬性值取決于某種具體上下文，則可考慮把該屬性重新表述為一個限定詞。(3)名稱：名稱常常作為限定詞而不是對象的屬性，當名稱不依賴于上下文關系時，名稱即為一個對象屬性，尤其是它不唯一時。(4)標識符：在考慮對象模糊性時，引入對象標識符表示，在對象模型中不列出這些對象標識符，它是隱含在對象模型中的，只列出存在于應用域的屬性。(5)內部值：若屬性描述了對外不透明的對象的內部狀態，則應從對象模型中刪除該屬性。(6)細化：忽略那些不可能對大多數操作有影響的屬性。5.使用繼承來細化類使用繼承來共享公共機構，以此來組織類，可以用兩種方式來進行。(1)自底向上通過把現有類的共同性質一般化為父類，尋找具有相似的屬性、關系或操作的類來發現繼承。有些一般化結構常常是基于客觀世界邊界的現有分類，只要可能，盡量使用現有概念。對稱性常有助于發現某些丟失的類。(2)自頂向下將現有的類細化為更具體的子類。具體化常常可以從應用域中明顯看出來。應用域中各枚舉字情況是最常見的具體化的來源。當同一關聯名出現多次且意義也相同時，應盡量具體化為相關聯的類。在類層次中，可以為具體的類分配屬性和關聯。各屬性都應分配給最一般的適合的類，有時也加上一些修正。6.完善對象模型對象建模不可能一次就能保證模型是完全正確的，軟件開發的整個過程就是一個不斷完善的過程。模型的不同組成部分多半是在不同的階段完成的，如果發現模型的缺陷，就必須返回到前期階段去修改，有些細化工作是在動態模型和功能模型完成之后才開始進行的。具體的完善過程如下：(1)對于丟失對象的情況分析及解決辦法：·若同一類中存在毫無關系的屬性和操作，則分解這個類，使各部分相互關聯；·若一般化體系不清楚，則可能分離扮演兩種角色的類；·若存在無目標類的操作，則找出并加上失去目標的類；·若存在名稱及目的相同的冗余關聯，則通過一般化創建丟失的父類，把關聯組織在一起。(2)查找多余的類。(3)若類中缺少屬性、操作和關聯，則可刪除這個類。(4)查找丟失的關聯。(5)若丟失了操作的訪問路徑，則加入新的關聯以回答查詢。10.3.3建立動態模型1.準備腳本動態分析從尋找事件開始，然后確定各對象的可能事件順序。在分析階段不考慮算法的執行，算法是實現模型的一部分。2.確定事件確定所有外部事件。事件包括所有來自或發往用戶的信息、外部設備的信號、輸入、轉換和動作，可以發現正常事件，但不能遺漏條件和異常事件。3.準備事件跟蹤表把腳本表示成一個事件跟蹤表，即不同對象之間的事件排序表，對象為表中的列，給每個對象分配一個獨立的列。4.構造狀態圖對各對象類建立狀態圖，反映對象接收和發送的事件，每個事件跟蹤都對應于狀態圖中的一條路徑。10.3.4建立功能模型功能模型用來說明值是如何計算的，表明值之間的依賴關系及相關的功能，數據流圖有助于表示功能依賴關系，其中的處理對應于狀態圖的活動和動作，其中的數據流對應于對象圖中的對象或屬性。建立功能模型的具體步驟如下：(1)確定輸入值、輸出值。先列出輸入、輸出值，輸入、輸出值是系統與外界之間的事件的參數。(2)建立數據流圖。數據流圖說明輸出值是怎樣從輸入值得來的，數據流圖通常按層次組織。10.3.5確定操作在建立對象模型時，確定了類、關聯、結構和屬性，還沒有確定操作。只有建立了動態模型和功能模型之后，才可能最后確定類的操作。10.4面向對象的設計1.面向對象設計的概念OOA主要通過對類的認定和劃分，以確定問題空間中存在的類、確定類和類的結構等，然后建立一個完整的分析模型。OOD將面向對象分析建立的分析模型變換成設計模型。軟件設計人員需要發現相關的對象，將它們的因子化為適當粒度的類、定義類的接口和繼承層次結構，并且建立它們之間的關系等。應避免重復設計，至少使重復設計降到最低程度。設計可重用的面向對象軟件是困難的，但是，人們總是在設計過程中充分利用重用技術。軟件設計完成后，設計人員都試圖重用它，并不斷地修改該設計，使它不斷完善和成熟。OOD把主要的系統構件組織為子系統的系統級“模塊”。數據和操作數據的方法被封裝為對象，對象(類)是OO系統的構造積木塊。OOD必須具有描述對象屬性的特定數據結構、數據組織以及個體操作過程的細節。OOD為了實現軟件需求，可能引入其他類和對象，也可能為提高軟件設計質量和效率而改進類結構。例如，重用類庫中的類，通過類的認定和類層次結構的組織，確定解空間中存在的類和類結構，并確定外部接口和主要數據結構等。OOA和OOD很難截然分開，也就是說，面向對象分析與面向對象設計之間不會用階段和時序來區分。但是，OOD建造系統仍然基于軟件設計的基本概念——抽象、信息隱藏、功能獨立、模塊性等。在傳統方法和OOD方法中有10種設計建模的主要構成成分，它們可以用于比較各種傳統方法和面向對象設計方法。這10種設計建模的主要構成成分是：①模塊層次的表示；②數據定義的規格；③過程邏輯的規格；④端到端處理序列的說明；⑤對象狀態和變遷的表示；⑥類及層次的定義；⑦類中操作的表示；⑧操作的詳細定義；⑨消息連接的規格；⑩排他服務的標識。2.面向對象系統設計模型傳統的設計方法有4個層次——體系結構設計、數據設計、接口設計和構件設計。OOD方法與傳統方法相比，也存在以下4個層次：(1)體系結構設計(系統設計)；(2)數據設計(當屬性被確定)；(3)接口設計(當消息模型被開發)；(4)構件設計(當對象被認定后進行對象設計等)。值得注意的是，OO設計的“體系結構”更多的是關注對象之間的協助，而不是構件間的功能控制流。系統模型設計過程如下：(1)子系統設計。一個軟件系統往往有幾個主要組成部分，可以按主題把主要的系統構件組織為子系統。子系統是可以相對獨立運作的，各子系統之間具有盡可能簡單的明確的接口。子系統設計應包括每一個子系統的表示，這些子系統能夠滿足用戶的軟件需求，并且實現支持用戶需求的技術設施。(2)類與對象設計。這里應該包括每一個類與對象的表示和類結構的創建。例如類的層次結構的創建，可以用一般化類以及不斷逼近目標的特殊化類的機制實現；組裝結構可以用分析類的聚集來實現。(3)消息設計。它包括每一個對象能夠與協作對象通信的設計細節。通過消息設計建立系統的內部和外部接口。(4)責任設計。它包括每一個對象的所有屬性和操作的數據結構以及算法設計(服務、方法的具體實現的細節)。在面向對象系統中，存在著類和通信對象重復出現的模式，利用這些模式可以解決特定的問題，使得面向對象設計更靈活和重用性更好。設計模式是基于過去的經驗而幫助設計者重用成功的設計，把設計模式應用于設計問題中，就不需要重復設計。在面向對象系統中，設計模式可以通過應用繼承和組合這兩種不同的機制被使用。使用繼承，現存的設計模式變成了新子類的模板，存在于模式中的屬性和操作也被子類所繼承而變成子類的一部分；組合導致對象的聚合概念。一個問題可能需要具有復雜功能的對象，復雜對象可以通過選擇一組設計模式并且聚合適當的對象組裝而成。當然可以考慮繼承和組合并存的方法，在實際設計中，往往組合要優先于繼承。過分地使用繼承會導致類層次越來越龐大而變得難以管理，組合關注的目標是小的類層次和對象，組合可以用不修改的方式使用現存的設計模式——重用構件。每一個設計模式可以被處理為黑盒，在模式之間的通信僅僅通過良好的接口來實現。Rumbaugh方法中的對象建模技術提出的設計活動，有兩個不同抽象的級別，即系統設計和對象設計。(1)系統設計。它著重于構造一個完整的軟件產品或者系統所有構件的布局。具體來說，系統分析模型被劃分為若干個子系統，然后被分配給處理器和任務，實現數據管理的策略被定義，訪問它們所需要的全局資源和控制被標識。(2)對象設計。它著重于個體對象的詳細布局。具體來說，從系統分析模型中，為對象選擇出操作，并且為每一個操作定義算法；適合于屬性和算法的數據結構被表示；類和類屬性的設計應該能夠優化對數據的訪問，并提高計算的功效；消息模型被創建，用以實現對象關聯。由Coad/Yourdon提出的OOD模型如圖10.25所示。該模型表示系統由4個部件組成，即垂直分成4個部分：①主體部件(PDC)設計(問題領域部分)；②用戶界面部件(HIC)設計(人機交互部分)；③任務管理部件(TMC)設計；④數據管理部件(DMC)設計。每一個部件又有5個層次，即水平切片分成5層：①主題層；②類與對象層；③結構層(分類、聚集)；④屬性層；⑤服務層。雖然有各種各樣的設計方法，每一種設計方法有各自不同的術語。但是，整體的OOD過程是基本一致的。為了完成面向對象設計，軟件設計人員應該完成下列步驟：(1)描述每個子系統并將其分配到處理器或任務；(2)選擇實現數據管理、界面支持和任務管理的設計策略；(3)為系統設計合適的控制機制；(4)通過創建每個操作的過程表示和類屬性的數據結構，從而完成對象設計；(5)使用對象間的協作和對象關系，完成消息設計；(6)創建消息模型；(7)評審設計模型并在需要時迭代。3.面向對象設計原則在傳統設計中，有5種標準用于判斷設計方法的模塊化能力，它也可以用于面向對象設計中。(1)分解性(Decomposability)：設計方法幫助設計者將一個大型問題分解為易于求解的子問題的程度。(2)組裝性(Composability)：設計方法保證程序構件(模塊)一旦被設計和建造后，可被重用創建其他系統的程度。(3)易理解性(Understandability)：程序構件在不參考其他信息或者其他模塊的情況下，易于理解的程度。(4)連貫性(Continuity)：在程序中進行小修改的能力，這些修改展示它們自己與一個或少數幾個模塊中對應修改的能力。(5)保護性(Protection)：如果一個錯誤在特定的模塊中發生，將減少副作用傳播的能力。優秀的面向對象設計應該權衡各種因素，降低設計成本，提高軟件的可維護性。根據以上5個設計標準可導出以下的基本原則：(1)模塊化。與傳統的設計方法一樣，面向對象設計方法也支持系統分解和系統模塊化的設計原理。實際上對象就可以理解為構件(模塊)，它是把數據結構和操作這些數據方法緊密地結合在一起的構件(模塊)。(2)抽象。面向對象方法不僅支持過程抽象，而且支持數據抽象。類實際上就是一種抽象數據類型，類的公共接口構成了類的規格說明，使用者通過類的接口就可以使用類中定義的數據，無須知道類中具體算法的實現細節和數據元素表示方法，通常把這類抽象稱為規格說明抽象。有一些面向對象語