診斷Java代碼系列-軟件開發未來數年內發展趨勢展望 (轉)

Java/j-djc06173/#author1">Eric E. Allen (Mailto:eallen@cs.rice.edu">eallen@cs.rice.edu)
Ph.D. candidate, Java編程語言小組，Rice大學
2003 年 8 月

在診斷Java代碼 系列最后一部分，Eric Allen 討論軟件開發的當前動態并展望未來數年內的發展趨勢。

尊敬的讀者：我非常遺憾的通知您這將是診斷Java代碼系列的最后一部分。我已經(最后)完成了我的博士學位工作，將前往行業實驗室幫助開始新的編程語言調研項目。

在這最后一篇文章中，讓我們來看看我們的水晶球。我們將討論一些軟件行業的流行動態，以及預計它們對軟件開發的未來產生的影響。我們將重點討論在過去兩年半內，我們在這一系列文章中使用的有效軟件開發。與往常一樣，我們將特別關注有效錯誤預防和診斷在使我們實現在日益復雜的數據領域中自由翱翔扮演的關鍵角色。

當調查行業整體發展方向時有三種流行動態需要考慮。它們是：

• 廣泛使用的無線計算的爆炸性增長
• 開發可靠軟件不斷增長的開銷
• 計算性能持續的快速完善

總之，這些動態正在重新塑造軟件和軟件開發過程中涉及的軟件工程的基本特性。從高處看，軟件開銷及其普遍性正在把我們引向更廣泛和更普遍的抽象概念，如強大的虛擬機器，具有精心定義的語義和安全特性，從而使我們能夠在更多的平臺上更輕松地開發和維系軟件。

同時， 計算性能的不斷完善使我們能夠構建這些抽象概念，不會蒙受無法接受的性能下降。 我非常愿意嘗試一些我認為我們可以構建新抽象概念的方法，它們將有助于創建下一代軟件產品。

基于組件的開發
在基于組件的開發中，軟件使用模塊進行開發，其外部引用從特定實施分解。然后這些模塊可以動態進行鏈接，以構建一個完全成熟的應用。注意“外部引用”不僅僅包括引用的對象，還包括可以使用的類，甚至子類。(想一想Java編程中不同包互相引用的方法?，F在考慮相互分解包。) 在這一專欄中，我們已經討論了一種關于基于組件的Java編程理念 -- Jiazzi (見 sources">參考資料 ，2002年月日11月專欄分解包相關性)。

基于組件的編程承諾兩種互補性優勢，隨著上述態勢變得越來越突出，這兩種優勢將變得日益重要。首先，基于組件的系統可以實現更大范圍的重新使用。例如，考慮到目前的無數程序，它們提供文本編輯支持(郵件客戶機、文字處理程序、ide等等)。同樣，考慮眾多提供處理電子郵件支持的客戶機。姑且不管提供這些業務的程序的數量，很少程序能夠處理電子郵件以及作為專用電子郵件客戶機。而且沒有郵件程序能夠實現與專用文本編輯器相同級別的文本控制。但為什么所有郵件客戶機(IDE、文字處理程序等等)必須開發自己的文本編輯器呢？如果有一個各種第三方組件可以實施的標準“文本編輯器”api那該多好??！郵件客戶機等工具可以選擇它們最喜歡的實施這一API的方法并把它加入。實際上，人們甚至可以想像，用戶使用現成的組件（如他們最喜歡的編輯器、他們最喜歡的郵件客戶機）來創建自己的環境，可以在應用運行時動態鏈接這些現成的組件。

基于組件的模式的另一種優勢是更大范圍測試的潛力。在Java語言中，類的外部引用，如I/O庫類和類似類，都是硬連線引用，如未重新編譯不能做任何更改。結果是，很難對單獨依靠外部引用的程序部份進行測試。例如，實際上如果不允許一個程序從文件系統進行讀和寫，很難測試它是否正確使用了該文件系統。但在單元測試中讀和寫文件會減緩測試，增加更多的復雜性(如創建臨時目錄和在使用后清除文件)。理想狀況是我們應分離程序和I/O庫的外部引用以便測試。

有多種方式我們可以用來標準化一個組件模式。J2EE在對象級別為web業務提供這樣一種模式。Eclipse為IDE組件提供一種模式。Jiazzi提供一種可以鏈接單獨編譯的軟件“單元”以形成一個完整的應用的模式。每種公式在特殊的環境中使用；我們期望在接下來的數年內看到更多的公式。

斷言和不變量 聯合基于組件的編程必須將越來越多的重點放在斷言和確保實際上滿足計劃預留用于組件的不變量的其它方法。類型系統自身并沒有表現得能夠捕獲所有計劃的不變量。例如，我們不應期望文本編輯API的方法類型可以捕獲所有與“只關閉打開的文件”類似的不變量。我們可以依靠非正式文件來規定這類不變量，我們標準化和檢查的不變量越多，效果就越好。

確保滿足需要的不變量是組件封裝的一個方面。通常，客戶機編程人員將無法推論組件如何運行，而不是按公布的API中所述的方式。API中不包括的組件的所有行為不是客戶機編程人員可以依靠的行為。如果非公布的行為導致運行時錯誤，編程人員將很難診斷問題并加以解決。

目前正在進行多項調研項目以顯著改進我們可以規定用于組件的不變量的種類。其中一些項目，如Time Rover (見 參考資料 2002年7月專欄)，使用模態邏輯和其它邏輯形式來表示運行時行為的深度屬性。

表示不變量的另一種方法是泛型－作為其它類型參數化的類型來支持類型系統(本專欄中最近一系列文章的主題)。

添加更加強大的不變量的另一種方法是從屬類型。 從屬類型是運行時值參數化的類型 (與泛型比較，泛型是其它類型參數化的類型)。

從屬類型的標準實例是數組大小參數化的數組。通過在該類型中包括數組大小，編譯時間檢測器可以象征性地分析數組的存取，確保所有存取都在數組范圍內進行。從屬類型另一種引人注目的使用方式是由 Boyapati、 Liskov和 Shrira開發的所有者（ownership）類型 (見參考資料 ，原始頁面鏈接)。

所有者類型是一個所有者對象參數化的對象的類型。例如，考慮容器上的迭代器（iterator）?？梢院茏匀坏恼f迭代器由容器擁有，因此，容器有該迭代器特殊的存取特權。內部類提供一些相同的存取特權控制，但所有者類型提供更強大、靈活的控制機制。

重整工具中的持續改進 軟件應用的規模越來越大，而程序人員越來越難以維持和改進代碼或診斷程序錯誤。優秀開發人員的缺乏進一步加劇了這一難題。幸運的是，開發工具正在為我們提供對軟件系統越來越強有力的控制。最強有力的兩種控制形式是單元測試工具和重整瀏覽器。

單元測試工具使我們能夠檢查重整情況下繼續保持的程序的關鍵不變量。重整瀏覽器提供多種直接且強有力地修改代碼的方式，同時保留行為。我們開始看到“第二代”單元測試工具，它們利用靜態類型和單元測試，從而實現代碼范圍的自動測試和測試的自動生成。重整瀏覽器向標準字庫添加越來越多的重整。從長期來看，我們應尋找更卓越的工具，如“以模板為導向”的重整瀏覽器，它承認設計模板在程序中的使用（或潛在使用）并應用它們。

我們甚至可以期望開發工具最終利用單元測試來執行更多積極地重整。在Martin Fowler的杰作《重整：完善現有代碼設計》中，重整被定義為保留程序看得見的行為。但是，我們通常不會關心一個程序看得見的行為的所有方面，實際上，我們通常只關心維持該行為的某些關鍵方面，而且這些關鍵方面正是假定要進行檢測的一組單元測試！

因此，重整瀏覽器可以潛在地利用一組單元測試來確定行為的重要方面。其它方面應可以被重整瀏覽器積極地隨意修改，以簡化程序。另一方面，通過確定單元測試允許的重整的種類并向程序人員報告，這類重整瀏覽器的功能應可以用于檢測測試范圍。

交互式調試器
隨著應用的日益復雜且更多地在遠程平臺上運行，程序錯誤的診斷帶來了新的挑戰。通常在部署平臺上調試程序是不可行或不切實踐的。最理想的情況是我們能夠遠程調試軟件。

Java平臺調試器架構(JPDA)提供用于這類工具，允許調試器在單元的JVM上運行；然后我們可以使用Rmi來進行遠程調試。而且，除了遠程調試之外，通過在啟動調試器時為程序人員提供更多的存取點控制，以及調試過程中提供計算狀態的可用視圖，程序人員可以更有效地進行診斷。

即使使用現代化調試器，程序人員在多種環境中仍舊必須求助于printlns 以獲得他們需要的信息。理想情況下我們應部署調試器，它可以完全取消printlns的需求。實際上，在Java編程語言小組(JavaPLT)中，我們正在研究這類調試器。由于開放源代碼將在2003年秋季發布，這類調試器將使用無縫集成的“交互式窗口”， 它支持代碼的漸進式評價(見參考資料，2002年3月專欄)。交互式窗口使您能夠通過任意表達式評估來啟動調試流程。它還可以在斷點使用，以與上下文中運行的流程交互，接入流程中該點看得見的范圍并隨意進行修改。JavaPLT 調試器將作為 DrJava IDE的一部分和作為單獨的Eclipse插件推出。

輕型、可互操作的開發工具
隨著開發工具變得越來越先進，一家廠商很難提供所有最好的工具。開發人員傾向于依靠不同廠商提供的工具自助餐。如果不同的工具能夠很好地協作，這樣做最好不過了，每個人都接受這樣一個事實，它們將與其它工具很好地協作。

Eclipse等項目在這一哲學方面搶得先機，提供實現工具互操作的方式以利用相互之間的功能，以及提供任何工具單獨提供的范疇之外的業務。隨著時間的推移，我們期望這種模式，或其它與其類似的模式，以真正“超越”傳統的全方位IDE。

元級別應用邏輯
根據我們最后的水晶球構想，我們考慮軟件行業可能在長時間內從事的一個方向。應用中發生的許多最常見的程序錯誤都是簡單的誤配置的結果，一旦用戶了解應用的基本詳細信息就可以輕松對其進行糾正。問題是大多數用戶沒有時間來了解他們使用的所有應用的基本詳細信息。

解決這一問題的一項長期解決方案是將元級別知識嵌入到應用中，這類應用對運行應用的環境以及假設要執行的程序進行編碼。例如，字處理程序的元級別知識應包括解釋用戶在個人計算機上用于生成英文文件的程序的邏輯，其它用戶可以閱讀這類文件。在對這類知識進行了編碼之后，當某些地方出錯時應用可以推論出用戶正在嘗試做的工作(當然，應用還必須首先確定某些地方出錯)。

這類元級別知識是向應用添加強韌性的潛在強大機制。它還極其危險，最令人不安的是在極力提倡沿著這一方向前進過程中經常忽略了它的存在。實際上，自身可以動態重新配置的應用的行為極其不可預測。用戶可能發現很難在某些情況下說明他的程序將如何運行。而且，程序的開發人員還可能發現很難確保其可靠性。正如我們反復看到的一樣，不能預測和了解程序行為導致的一種可以輕松預測到的結果是 -- 錯誤不斷的軟件。

為了弄清楚這一點，我真正考慮具有元級別知識的適應軟件，這類知識與有可能顯著提升軟件應用性能的環境有關，但如果我們增加了這類功能，那么我們必須找到相應的方法，從而仍舊使我們能夠有效說明我們的程序。

一個結合元級別知識形式和功能（雖然非常有限）且不會影響可預測行為的軟件系統實例是TiVo個人數字記錄器(或其它類似產品)。TiVo根據您的看電視習慣來自適應地確定您可能希望觀看的節目，但這種自適應性是極其受限制的。TiVo將總是遵循用戶的節目指令來記錄，與任何其自適應行為響應無關。TiVo使用一種非常簡單的元級別知識形式，但隨著使用的元級別知識變得越來越復雜，我們應繼續保持對自適應行為的控制。如果您將認可科幻領域某些稀奇的比較，那么我們將遵循Isaac Asimov創建的先例。Asimovian機器人是異常強大的機器，但它們必須絕對遵循不可侵犯的基本法律，從而能夠在一定程度上預測它們的行為。

再會
在Asimovian機器人注釋中我將結束這一討論。非常感謝 developerWorks 小組在過去兩年半的時間內所做的工作：編輯Jenni Aloi，為我提供編寫這專欄的機會；文字編輯Christine Stackel，對細節一絲不茍；發展編輯 Kane Scarlett，進一步完善了這一專欄的內容。

致讀者：非常希望您能夠在這些文章中挖掘出一些最新的價值。對于我來說，撰寫這些文章已經成為了無價的學習體驗。非常感謝您閱讀這類文章，祝您在防止和診斷程序錯誤中好運。

BIOS-->

關于作者
Eric Allen 在康奈爾大學獲得計算機科學及數學學士學位，并且是 Rice 大學 Java 編程語言小組的博士研究生。在回 Rice 完成學位前，Eric 是 Cycorp, Inc. 的首席 Java 軟件開發人員。他還主持了 JavaWorld 的“Java 初學者”論壇。他的研究包括源代碼和字節碼級別上 Java 語言的語義模型和靜態分析工具的開發。Eric 領導開發了 Rice 的 NextGen 編程語言的實驗編譯器，NextGen 編程語言是帶附加語言特性的 Java 語言擴展，他也是 DrJava（一種為初學者設計的開放源碼 Java IDE）的項目經理?？赏ㄟ^ eallen@cs.rice.edu與Eric聯系。