軟件組件技術在歐特克產品中的應用

曾邱雪

0 引言

“面向對象”最初的定義，是指：在具備封裝、類型擴展性、繼承、多態等特點的程序設計方法，隨著軟件產業的進一步發展，面向對象技術現在具備更加廣泛的意義并且滲入到軟件開發的各個方面。隨著軟件越來越龐大，要求越來越高，如何快速高質量地開發出優秀的軟件，傳統的軟件開發方法已顯乏力，開發和采用可復用的軟件功能模塊—軟件組件技術便成為解決此問題的最佳方法之一。軟件組件技術是一些可執行單元，可以通過獨立的開發和配置，然后整合到各個獨立的軟件系統中去，是軟件系統內被標識、符合某種標準要求的組成部分。在過去數年中，基于軟件組件技術的開發方法備受關注，并且成功運用于多種大型軟件中，取得了不錯的效果。

1 組件技術的應用

通過采用恰當的組件技術，軟件廠商得以通過降低投入，縮短開發周期和增加軟件質量來達到提高收益的目的。近年來，基于組件的軟件技術的成熟程度和推廣速度日益增長，新的應用軟件工程碩士開發技術和工具，是以組件作為關鍵，復用大粒度的對象，為的是快速的開發出應用軟件。組件技術尤其適合由若干大型軟件組成的軟件套件，非常著名的例子，有微軟公司的OFFICE辦公套件以及Adobe公司的創新套件。通過采用軟件組件技術，實現各個軟件直接無縫地協同工作，極大挖掘了軟件的功能，極大地方便和改善了用戶對軟件套件的學習和使用，提高用戶對產品的忠誠度，提高了用戶體驗。

社會經濟不斷發展，為2D/3D計算機輔助設計軟件行業，提供了巨大的發展機會，然而，隨著業務的發展，新的業務品種不斷增加，必須在原有業務系統上不斷擴展改造，而且各個獨立軟件之間的協作需求不斷出現。因此，必須尋求新的協同合作方案來解決這個問題。希望通過新方案的應用，達到在各個實現各個獨立軟件直接的無障礙交互，達到整合不同產品優勢功能的目的，最終有效地幫助用戶提高整個行業業務效率。

1.1 計算機輔助設計軟件產業的需求

歐特克(Autodesk)公司是全球二維和三維設計、工程及娛樂軟件的領導者，其代表產品有：AutoCAD, Revit,Inventor, 3dsMax, Maya等多款計算機輔助設計軟件，橫跨Windows, Mac, Andriod 和iOS等多個平臺, 廣泛運用于工業和娛樂行業。目前計算機輔助設計產業中，常見的有機械設計、多媒體設計、計算輔助分析、以及其它方面。終端用戶往往需要同時使用幾款軟件以組合的方式來實現最終目標，這就產生了需要在幾款軟件之間進行交互的需求。如用戶需要使用AutoCAD進行設計繪圖，然后需要使用3dsMax進行渲染，又同時需要使用Revit進行建筑結構分析。由此可見，整個工作流程需要用戶對各款軟件都能熟悉使用，并且可能出現一個項目需要在多個軟件里重復建模的工作，由此產生不小的冗余工作。初始階段，這幾款軟件的文件格式是互不兼容的，軟件的用戶體驗也完全不一樣，導致用戶上手學習難度極大，設計效率不高。

歐特克公司的產品設計師通過和用戶的充分接觸，深入探討用戶工作中的各個案例，分析和提煉用戶反饋后總結出如下需求：

1) 各個軟件的文件格式能互相兼容，實現在一個軟件中建模，多個軟件中使用的目的。

2) 各個軟件的用戶界面應具有同樣風格，方便用戶上手。

3) 各個軟件中的相似功能應該具有類似或者一致的操作方式。

4) 各個軟件之間能夠互相協同工作，以提高用戶工作效率。

5) 用戶希望能夠增加方便分享設計文檔或資源的功能。

6) 用戶希望在移動設備上運行輕量級別的設計軟件。

1.2 軟件開發的技術需求

上世紀80年代起，面向對象的軟件開發思想迅速發展起來，這時的軟件組件的含義就是類庫。90年代后，組件的內涵進一步加強，聚合性、獨立性和重用性進一步提高。目前，基于對象的組件軟件體系結構中的組件是指可方便地插入到語言、工具、操作系統、網絡系統中的二進制代碼和數據。綜合上述組件技術的優勢，顯然，組件技術即是實現此項需求的最佳選擇。換一句話說，我們能夠從上述用戶需求中，提煉出其核心，就是希望各個軟件能夠互相“兼容”各個軟件的文件格式、交互界面、設計流程以及通信交互方式等。

1.3 軟件組件的提取

結合歐特克各個主要軟件的特征，產品設計師和軟件架構師協同合作，從高層次的用戶工作流程開始，逐個分析用戶案例并且提取出其涉及到的軟件組件。從抽象的軟件層，可以把組件類型劃分成如下幾個類別：

1.3.1 交互界面組件

此組件的主要功能，是根據工程設計軟件的特性，實現一套高效、用戶友好的通用交互界面庫，包括：程序主體框架、程序菜單、個性化的工具條、狀態欄。通過采用該組件，可以使不同產品具有相似的交互界面，極大提高用戶的軟件使用效率，方便用戶學習，并且能提高用戶忠誠度。在軟件工程方面，通過采用組件技術，可以減少各個軟件在界面上的冗余代碼，讓各個產品團隊能專注于各自的核心功能。

1.3.2 網絡服務組件

隨著互聯網運用的興起，各種基于網絡的運用遍地開花，如云計算服務、資訊訂閱、網絡搜索、用戶交流等功能，也將會出現在歐特克的各個產品中。本組件將實現基礎網絡組件的功能，以達到用戶注冊一個帳號，就能在歐特克各個產品上使用的目的，并且各個產品只需要簡單集成本組件即能具有網絡服務功能。

1.3.3 文件格式組件

本組件實現統一的文件格式，用于實現用戶在各個軟件之間傳遞設計模型的目的。其最終目的是讓各個產品能公用一種文件格式，最終達到無障礙交互。

1.3.4 材質庫組件

此組件實現了對2D/3D軟件中常用的材質庫的瀏覽、編輯和保存，以實現不同產品中共同功能模塊的共享，在降低軟件開發難度的同時達到提高用戶認同度的目的，并且讓用戶只需要學會一款產品中的功能，就能掌握幾款軟件中同樣功能的目的。本組件還能保證幾種軟件使用同樣的材質，掃除在交互期的障礙。

1.3.5 渲染引擎組件

渲染引擎是圖形類軟件的核心技術。本組件的目的是打造特殊與歐特克的跨平臺圖形引擎，在掌握核心技術的同時能夠提高軟件的質量。

1.3.6 許可證組件

每一個收費產品都必須擁有許可證部件來授權合法用戶，以保證生產廠商的版權。本組件的目的就是為歐特克所有產品提供通用的許可證組件，方便各個軟件產品的集成的同時能夠簡化用戶的激活步驟，并且為多個產品同時授權提供技術基礎。

1.3.7 其它

歐特克許多產品，還具有其它一些可以組件化的模塊，比如用戶反饋模塊，提供了收集用戶使用軟件的信息功能，并且能夠從海量數據中生成報表，方便產品設計師查詢、分析用戶使用習慣，最終優化產品設計提高產品質量。

1.4 軟件組件的實現

1.4.1 需求分析

軟件組件項目有著一個顯著的特點，那就是它的用戶首先是使用本組件的軟件產品，然后還可能有終端用戶。簡單地說，就是一個軟件組件首先是被另外一個軟件產品使用，集成到某一個產品中，然后伴隨這個產品發布到最終的用戶手中。毫無疑問，每個軟件產品都有著各自的開發背景，自然就會形成特殊的風格和特點，而這又會促使它們對組件的要求有著一定的差異性。舉一個簡單的例子，每一款軟件產品都有著各自獨特的網絡服務，如 A產品可能提供網絡存儲服務，而 B產品提供用戶互動支持，顯然它們對網絡組件就有著不同的側重點。由此，總結出軟件組件項目需求分析中需要注意的有：

根據項目周期，提前向用戶（包括軟件產品團隊，終端用戶）發出用戶需求收集請求。這是因為組件項目的開發時間往往是比軟件產品的開發時間提前一段3到6個月。

收到軟件產品團隊需求之后，需要迅速歸納分析各方需求，并且組織相關人員分析、評價。往往還需要在各個產品團隊之間進行協調和取舍。這是一個迭代的過程，一般需要進行多次。

需求分析中應恰當考慮有可能出現的需求變動。

需求分析完成之后，發出報告給各個軟件產品團隊進行確認和簽收。

1.4.2 設計與實現

軟件組件項目的設計與實現除了需要遵循一般的軟件設計準則之外，還有的其特殊之處。主要體現在：

軟件組件項目需要提供大量的API，因此軟件框架首先就考慮如何組織這些API。

軟件組件項目需要提供良好的兼容性，框架需要支持多種需求，并且要考慮向前和向后的兼容性。

軟件組件項目需要方便用戶集成，并且提供良好的集成文檔。

軟件組件項目需要提供良好的擴展性。

軟件組件項目需要提供良好的性能。

軟件組件項目可能需要跨平臺。

軟件組件項目需要考慮如何測試。

軟件組件項目需要考慮組件與組件之間的相互依賴。

為了在軟件組件中達成上述目標，我們在軟件組件項目中經常采用下列設計模式：

1) 單件模式

單件模式常常用來創建組件的管理者（有些書籍中也會稱管理者為一種模式），通過管理者來管理組件和設置全局屬性。這是因為組件中常常需要提供接口，給用戶來設置一些針對組件的全局選項，如組件的內存處理方式，組件的延時加載選項等。

2) 橋梁模式

此模式常常用于組件的C++ API中，主要的思想就是在 API類中不添加真正的實現代碼，而是通過一個橋梁來轉換到另外一個實現類中，達到保證API類內存狀態穩定，達到保證組件庫的兼容性的目的。雖然此模式會增加一定的代碼量，但是相對于其帶來的好處，還是非常值得使用的。

3) 策略模式

通過采用策略模式，可以為同一個接口提供不同的實現，達到為不同的需求提供不同服務的目的。這是因為，不同的用戶對同一個功能可能需要采用不同的算法或者實現，但是，其上層接口往往是一樣的，因此經常使用策略模式來封裝一種算法（或實現），并使得它們可以互換。其典型實現，如圖1所示：

圖1 策略模式

4) 裝飾模式

通過采用裝飾模式，可以方便地為不同用戶提供不同的服務。不同用戶所使用的功能往往不相同，如 A用戶可以使用上述1，2，3功能，而B用戶卻只需要1這一個功能，因此我們常常使用裝飾模式來方便用戶選擇他需要的功能。其典型實現，如圖2所示：

圖2 裝飾模式

5) 命令模式

通過命令模式，可以方便向軟件用戶反饋組件中出現的命令，方便用戶對此做出正確反映。其典型實現，如圖3所示：

圖3 命令模式

6) 觀察者模式

通過觀察者模式，可以方便實現軟件組件和一個或者多個用戶的通信合作，一般用于組件向軟件端回調一些函數。其典型實現，如圖4所示：

圖4 觀察者模式

1.4.3 組件的測試

編碼工作完成后需要進行軟件組件的測試工作，它主要包括兩個方面：

1) 傳統的測試項目

類似于傳統的軟件測試，根據項目設計文檔進行測試，但是其一顯著特點是進行大量的 API測試和在有限的環境中盡量模擬真實的運行環境進行測試。

2) 集成測試和兼容性測試。

這是屬于軟件組件項目特殊的測試項目，那就是需要測試軟件組件能否滿足用戶提出來的集成需求測試，這往往需要團隊和軟件產品團隊協同合作完成。另一方面就是需要測試組件項目的兼容性，主要指的是向上兼容性，因此這個測試需求僅僅出現于版本更新的項目上。

1.4.4 發布與技術支持

軟件組件項目在發布之后并沒有真正的結束，通常需要為接下來的集成工作提供技術支持甚至修改軟件組件。根據上面提到的，組件項目往往比使用它的軟件產品項目提前3到6個月，實際上軟件組件的集成工作一般都開始與軟件組件即將完成的時候，一直延續到完成之后的一段時間。這個時候組件項目需要為集成工作，提供大量的支持工作，解決項目中出現的問題。

1.5 經驗和心得

組件項目有的特殊的用戶和定位，因此其具有不同于一般軟件項目的特點。根據作者多年軟件組件開發經驗，得出以下經驗和心得：

1) 開始階段的需求溝通非常重要，由于組件項目先于產品團隊開發，因此需要催促產品團隊提供需求，并且需要在充分溝通的前提下平衡各方的需求。而且需求肯定會有一定的變化，需要早做準備。

2) API架構時期，需要組件團隊的開發人員和用戶團隊的開發人員積極溝通，爭取以最簡單的方式實現健壯的API框架。API用法越簡單越好。

3) 從項目開始就注意項目文檔，并且把它作為一個任務來追蹤。

4) 在API框架以及主要功能完成的前提下，盡早提交產品團隊進行集成，測試。

5) 很多重要的問題往往在產品集成之后才能暴露出來，如兼容性，產品性能問題，需要提前為此做好準備。

6) 理智面對用戶在項目后期提出的新的需求或者變更，需要妥善討論并且和各個用戶溝通之后再確認是否接受此更新。

2 組件技術實施效果分析

歐特克產品在采用組件技術后，顯著地避免了各個產品各自實現一些常用模塊的現狀，減低了代碼的冗余度，提高了開發速度。更加重要的是，用戶對這些改變提供了積極的反饋，歐特克公司將繼續深化此解決方案并且在此基礎之上推出軟件套件策略。

3 結束語

由于移動操作系統的興起，開發軟件的差異導致組件也是多種多樣，對軟件組件技術帶來新的機會和挑戰，毫無疑問組件技術本身也會在需求的推動下不斷前進。

[1]鄭人杰，殷人昆，陶永雷. 實用軟件工程[M].北京：清華大學出版社，2004

[2]Ira Pohl 著.陳朔鷹，馬銳，薛靜鋒，呂坤 譯. C++教程[M].北京：人民郵電出版社，2007

[3]（美）弗里曼（Freeman，E.）等著. Oreily Taiwan公司譯.Head First 設計模式（中文版）[M].北京：中國電力出版社，2007

[4]陳文實，孟憲宇，李賽男. 中間件技術的應用及前景[J].遼寧：遼寧工學院學報(自然科學版)，2004年3期