試論物件導向軟體的維護 (轉)

試論物件導向軟體的維護 (轉)[@more@]

試論面向的維護
吳會松

目錄
摘要：
1 問題的提出
2 物件導向的軟體易於修改但不易理解
3 物件導向軟體的理解、分析
  3.1 理解、分析物件導向軟體的一般方法
  3.2 對(使複雜化的)繼承機制的分析
  3.3 對具有密切關係的類集團的分析
4 物件導向軟體的動態聯接及多型性
5 幾點建議
6 結束語

 

摘要：

　　用物件導向的方法開發軟體已漸成潮流，人們也普遍認為物件導向軟體的維護應不成問題，但事實卻非如此。隨著物件導向技術的廣泛使用，物件導向軟體不易維護(原因是維護者不易分析、理解這類軟體)的問題已越來越突出。本文在討論物件導向技術對軟體維護影響的基礎上，探討了物件導向軟體的維護問題，並提出瞭解決的對策。

1 問題的提出

　　所有軟體都會有一個代價高昂的維護階段。很多人的表明：少數維護是改正性維護，多數維護屬適應性(或改善性)維護。不管一個軟體有多麼好，都會要求有更強的功能、更好的適應性。多年的實踐表明：只有不斷的維護，軟體產品才有生命力。

　　現在採用物件導向的方法開發軟體已漸成潮流，因為物件導向具有一些結構化方法所不具備的優點，對提高軟體的開發質量和開發極為有益[1]。但物件導向軟體也需要代價高昂的維護[2]，這種代價往往會超過時的投入。因為開發時採用的技術不同，軟體維護時所面臨的問題亦不同，所以我們必須重視物件導向軟體的維護問題。鑑於此，本文準備根據物件導向技術的特點，詳細探討物件導向軟體所面臨的維護問題及我們應該採取的對策。

2 物件導向的軟體易於修改但不易理解

　　同所有軟體一樣，物件導向軟體的維護也需要兩個基本條件：①. 待維護的軟體可以理解；②..待維護的軟體可以修改、在軟體維護中，只有先理解程式，然後才能修改程式。

　　理解程式的關鍵問題是維護人員能重構"源設計圖"，並掌握原設計人的設計思想和方法、策略。如果這些思想、方法、策略都集中在一段不大的程式裡，那麼理解起來還容易一些。但用物件導向技術開發出來的程式往往存在於不連續的程式段中(比如一個方法可能有一段程式，而一個物件中可能有多個各自獨立的方法)，這時維護者就容易產生錯誤的理解，並據此作出錯誤的修改。

　　物件導向技術的要點，就是把問題抽象成各個物件並封裝之[3]。物件內部的訊息傳遞機制、靠訊息啟用方法的手段，以及物件間的並行、繼承、傳遞、啟用等特性，必然會導致軟體各部分之間存在著大量的複雜關係。這些物件導向所固有的特色，使程式設計師們已習慣的閱讀、分析、理解程式的方法失去了作用，這也會大大增加理解軟體的難度。

　　而對一個已理解軟體的修改卻容易得多，因為物件導向軟體中的物件能夠比較完整地反映客觀事物的靜態屬性和動態行為[4]，繼承機制又可以有效地使修改量降至最低，再加上物件封裝的屏閉作用(對一個物件的修改可以不影響其它物件)，所以物件導向的軟體易於修改[5]。

　　綜上所述，我們可以得知：如果我們已經理解了一個物件導向的軟體，那麼這個軟體修改起來就很容易(與其它型別的軟體相比)，但物件導向的軟體卻不易理解。

3 物件導向軟體的理解、分析

3.1 理解、分析物件導向軟體的一般方法

　　理解是維護的基礎，而重構"源設計圖"則是理解的基礎。在重構"源設計圖"時，因為物件的多型性、繼承機制以及動態聯接等特性，給理解原設計增加了困難。為了日後維護的方便，應在開發時就使軟體的設計思想易於理解(但由於開發中難以避免的變動，很難保證最終軟體的易理解性)，軟體開發環境也應提供能幫助維護者理解原軟體設計思路和策略的工具(眼下這種工具太少)。

　　按一般習慣理解一個程式段時，應先完成對程式的靜態分析，在查閱文件及程式程式碼的同時，要努力搞清這個程式段的用途及設計思想。維護人員需要查清這個程式段從何處被，這段程式碼所呼叫的其它過程、呼叫的前提條件、這些過程的功能及資料流動情況，這樣才能真正瞭解、掌握這段程式碼。對於物件導向的程式碼，還必須考慮它的一些特殊點。

　　為了理解物件導向的軟體，應在獲取了該軟體文件的前提下，分析、研究各物件的組織結構，以及各物件間的相互作用關係，在此基礎上遂步識別出程式中的物件、物件間的關係，並掌握各物件中各方法被啟用的條件、訊息的來源及傳遞的途徑。在現有的技術條件下，有些東西只靠資料往往很難搞清楚，最好找到原開發人員，請他們介紹必須的內容。

3.2 對(使程式複雜化的)繼承機制的分析

　　為了理解程式，就必須搞清楚程式的依賴性(包括其中的呼叫及資料流的相互關係)。物件導向程式中廣泛使用的繼承機制為查詢、分析程式的依賴性增加了困難。人們在分析一段程式時，必須考慮它是否存在於某些特定的上下文之中？該程式段是否依賴於某個(些)物件類中的方法[6]？讓人頭痛的是，這個方法有可能是由其子類中的一個成員所操縱的，而操縱該方法的例項變元既可以在類中進行說明，也可以在其子類中的一個成員中進行說明[7]。在圖1的示例中，例項變元"職員程式碼"在"職員"類中說明，可以由其它子類繼承。維護小組在分析"技術工"類中的"計算工資"方法時，若遇到"職員程式碼"，就得向上層(可能有多層)類中查詢這個變元的說明及註釋。

　　在物件導向軟體的開發過程中，隨著新物件的不斷增加，繼承關係的層次也可能會增加，這往往會使繼承關係變得更加複雜。例如：維護人員如果需要檢查一個訊息傳送，就需要檢查若干層，才能確定該訊息的接收者(即某個物件)。這種檢查無疑增加了理解程式的難度。

　　在開發軟體時，為避免減弱資料的封裝性，同時保證類的功能，程式設計師們很自然地把物件內的方法做得短小而簡單，小方法的數量因此而大大增加。這些大量存在的小方法往往使得中的繼承關係鏈變得很長，顯然，這也會增加分析的難度。

3.3 對具有密切關係的類集團的分析

　　物件導向的軟體中總有一些關係密切的物件(它們透過密切配合來完成一個特定的任務)[8]，筆者把這些物件類稱為具有密切關係的類集團(以下簡稱"密類集團")。維護者要想理類集團內每個類中的方法，就必須理解這個密類集團的整個執行機制，這就需要跟蹤所有可能的訊息傳遞序列，其工作量相當巨大。因此，密類集團的存在加大了閱讀、理解程式的難度。 　　在目前缺少分析工具的情況下，為了以後的維護，就必須在軟體文件中記錄好密類集團的活動過程，對各物件中的方法實行跟蹤。在測試時，要記錄好訊息傳送的序列、條件、時間、來源及處理結果的去處。這種完整的記錄可以減輕以後維護人員分析、理解軟體的難度，最終提高軟體的可維護性。

4 物件導向軟體的動態聯接及多型性

　　動態聯接及多型性會給軟體維護帶來分析上的困難。例如，在圖1的示例中，"印工資表"的方法中包含了下面(Visual FoxPro3.0指令)的程式碼[9]：

　　this.JSGZ()

　　這條程式碼向當前物件發出了"計算工資"的訊息。但現在有三個物件都含有名為"計算工資"的方法，對於支援動態聯接的語言，顯然我們無法根據這條指令就能確定程式會執行這三個方法中的那一個。所有維護者在分析這條指令時都得考慮到這三種可能性。對於我們使用的分析工具來說，也必須對這三種方法進行掃描。

　　如果只使用靜態聯接，而且程式碼的上下文提供了相應的資訊，人們可以據此推匯出相應的類，但仍有被誤導的可能。因為處理一個訊息可以用庫中的多種方法，一個人又很難記住這些方法對訊息的響應，這時出現理解失誤的可能性極大。

　　筆者認為，產生困難的關鍵是各物件的語義。如果開發者能保證多型一致性，使所有方法對某個訊息都產生相同的反映，那麼問題就會少一些。但如果方法的名子不一樣，維護者仍會產生誤解，因為一個方法有少量不同的行為，它們會改變整個程式碼段的含義。

　　維護人員可以透過比較"外部依賴圖"來發現這種不一致[10]。外部依賴圖是一種比較有效的檢測工具，當一個方法被啟動時，它可以自動地用資料流圖的方法來確定可能建立起來的資料項依賴關係。若設計人員能正確地使用多型性，那麼具有相同名子的方法就會有相同形式的外部依賴圖，這樣軟體工具就能比較由相同訊息啟動的方法的外部依賴圖，並對不同點作標記，方便維護人員的分析。

　　對一個軟體來說，多型性和動態聯接具有不同的兩面：優點是使程式具有靈活性[4](這是物件導向設計的目標之一，也是其特有的技術魅力)；缺點是給人們理解軟體帶來了困難，從而增加了維護的難度。為了提高物件導向軟體的可維護性，目前還需要有關權威機構建立一個控制、規範動態聯接和多型性使用的標準，最大限度地減少這方面的任意性。

5 幾點建議

　　總的來看，物件導向的方法具有很多優點，但在維護上卻產生了一些難點，主要是增加了維護者理解、分析軟體的難度。 為了減輕物件導向軟體維護的難度，綜上所述，建議採用以下措施：

　　a.研製針對物件導向軟體特點的維護工具，幫助人們分析、理解軟體。

　　b.軟體開發人員在使用物件導向的某些技術(如繼承、動態聯接等)時要特別小心。因為這些軟體機制類似於傳統方法中的GOTO語句，雖然有其好處，但使用不當也會帶來維護及上的困難。

　　c. 有關權威機構或軟體的開發組織應儘快建立一個控制、規範動態聯接和多型性使用的標準，最大限度地減少這方面的任意性。在目前缺少權威標準的情況下，開發軟體的專案組應先確定自己的標準，把該標準形成文字，作為軟體文件的一部分，以減輕後續分析的難度。

　　d. 開發人員要在文件中作好記錄，特別要記錄好具有密切關係的類集團的活動及測試過程，使文件能儘量全面地反映軟體的情況。

6 結束語

　　幾年前就有學者認為：物件導向的方法必將取代結構化方法。現在看來，"取代"還為時過早，目前見得比較多的還是兩者的結合物。因為物件導向的方法還是一種有待完善的技術，目前完全用這種技術開發的軟體還不很多，完全物件導向的大型應用軟體就更少了，尚未進入全面維護階段，人們還缺少維護經驗。所以我們目前對物件導向軟體的維護問題還缺少足夠的認識和措施，因此必須抓緊這方面的研究，為未來的大規模維護工作鋪平道路。