1 軟件重用

軟件重用技術是一種重要的軟件開發方法，雖然至今軟件重用技術還不夠成熟，離理想中的軟件工廠還有很長的路要走，但現有的一些重用技術（例如，中間件 、 應用服務器等）已經改變了開發過程。

1.1 軟件重用形式

軟件產品與其他的產品不同，是抽象的，一旦產生就可以無限制地復制，因此重復利用軟件產品的意義重大，可以節約大量的人力物力。軟件重用指的是利用已經存在的軟件元素建立新的軟件系統，這其中的軟件元素既可以是軟件產品 、 源程序，也可以是文檔 、 設計思想甚至是領域知識。軟件重用可以直接提高軟件的開發效率 、 降低軟件的開發成本 、 縮短軟件的開發周期 、 提高軟件質量。

常見的軟件重用形式包括：

（1）源代碼重用

這是最簡單也是最常見的重用形式，但由于軟件系統的復雜性，很難大規模地重用已有源代碼。

（2）架構重用

架構重用也很常見，隨著軟件架構風格和設計模式的推廣和應用，架構重用已經對軟件開發產生了重大的影響。

（3）應用框架的重用

隨著軟件技術的發展，應用框架的重用變得越來越普遍，很多成熟的軟件公司都建立了自己的開發框架。在開源社區中，世界各地的技術愛好者也在不斷地推出應用了各種新技術的開發框架，例如，應用了 AOP （ Aspect Oriented Programming ，面向方面編程）技術的 Spring 等。

（4）業務建模的重用

雖然不同的軟件的業務領域各自不同，但人們還是總結出了一些常見領域的建模方法，重用這些領域模型可以降低因領域知識不足而造成的需求風險。

（5）文檔及過程的重用

軟件文檔和軟件過程也是軟件開發中不可或缺的元素，有效地重用這些文檔和過程也有助于提高開發效率和軟件質量 、 降低開發成本。

（6）軟件服務的重用

隨著 Web 服務的提出，人們越來越關注服務的重用 。SOA （ Service-Oriented Architecture ，面向服務的架構）提出了面向服務的軟件架構，并定義了相應的標準。

1.2 構件技術

構件又稱為組件，是一個自包容 、 可復用的程序集。首先，構件是一個程序集，或者說是一組程序的集合。這個集合可能會以各種方式體現出來，如源程序或二進制的代碼。這個集合整體向外提供統一的訪問接口，構件外部只能通過接口來訪問構件，而不能直接操作構件的內部。

構件的兩個最重要的特性是自包容與可重用。自包容指的是構件的本身是一個功能完整的獨立體，構件內部與外部的功能界限清晰明確，可以獨立配置與使用。而可重用既是構件的特點，也是構件出現的目的。早在 1968 年 NATO 軟件工程會議， Mcllroy 的論文 《 大量生產的軟件構件 》 中，就提出了 “ 軟件組裝生產線 ” 的思想。從那以后，使用構件技術實現軟件復用，采用 “ 搭積木 ” 的方式生產軟件，就成為軟件人員的夢想。

構件的開發者和使用者往往不是相同的人或組織，所以必須定義構件的標準才能夠消除其中的障礙。隨著構件技術的發展，目前應用比較廣泛的構件標準有 CORBA、JavaBean/EJB、COM/DCOM。

（1）CORBA

CORBA（Common ObjectRequest Broker Architecture 公共對象請求代理體系結構）是由OMG組織制訂的一種標準的面向對象應用程序體系規范。

CORBA 有很廣泛的應用，它易于集成各廠商的不同計算機，從大型機一直到微型內嵌式系統的終端桌面，是針對大中型企業應用的優秀的中間件。最重要的是，它使服務器真正能夠實現高速度 、 高穩定性處理大量用戶的訪問?，F在很多大型網站后端的服務器都運行 CORBA。

（2）JavaBean/EJB

JavaBean在一般情況下指的是實體類，在大部分情況下和POJO是同義詞，基本構成就是一些字段和與之對應的 setter、getter方法，如果一個JavaBean需要在不同的JVM的進程中進行傳遞，還需要實現Serializable接口。

EJB = Enterprise Java Bean，現在已經很少使用了。

（3）COM/DCOM

COM(Component Object Model) 提供了一個 Windows 平臺上的對象通訊技術，并且逐漸成為應用程序之間彼此通訊及互動的技術主流，那么 DCOM(Distributed COM) 則是解決了計算機的通信和互動技術。

COM 的著眼點是在于同一臺計算機上不同應用程序之間的通訊需求，跨到另外一臺計算機之外，就不是一開始 COM 所設想到的領域。所幸跨程序的通訊和跨計算機的通訊差異僅在于通訊協議的處理 ( 也就是定位問題 ) ，對于數據交換上的處理并不會因此而有區別。所以要讓 COM 的環境能更進一步延伸到跨計算機的領域，只要妥善解決計算機定位的需求，就有機會克服。同樣幸運的是， COM 在一開始的設計中完全不去碰觸跨計算機的問題，使得要在 COM 的架構之上再架上一層跨計算機的處理環境并不會去破壞到原本的架構。于是 COM 的網絡延伸版本 DCOM(Distributed COM) 就此出現，負責讓 COM 組件可以在網絡環境下持續提供服務。 DCOM 最主要處理的是兩個議題，第一個議題是網絡通訊能力，第二個議題則是權限的問題。之前 COM 是在同一臺計算機中找特定的組件，而 DCOM 則要更進一步去找網絡上的某臺計算機，之后沿用 COM 的機制找到計算機上的組件。

COM+倡導一種新的設計概念，把COM組件提升到應用層，把底層細節留給操作系統，使COM+與操作系統的結合更加緊密。COM+的底層結構仍然以COM為基礎，但在應用方式上則更多地繼承了MTS（Microsoft Transaction Server）的處理機制，包括MTS的對象環境、安全模型、配置管理等。COM+把COM、DCOM和MTS三者有機地統一起來，同時也新增了一些服務，如負載平衡、內存數據庫、事件模型、隊列服務等，形成一個概念新、功能強的組件體系結構，使得COM+形成真正適合于企業應用的組件技術。

2 基于架構的軟件設計

基于架構的軟件設計（ Architecture-Based Software Design ， ABSD ）是一種架構驅動方法。這種方法有3個基礎：

（1）功能的分解。在功能分解中， ABSD 方法使用已有的基于模塊的內聚和耦合技術。
（2）通過選擇架構風格來實現質量和業務需求。
（3）軟件模板的使用。軟件模板利用了一些軟件系統的結構。

然而，對于設計方法來說，軟件模板的使用是一個新概念，下面，我們進行簡單的介紹。軟件模板是一個特殊類型的軟件元素，包括描述所有這種類型的元素在共享服務和底層構造的基礎上如何進行交互。軟件模板還包括屬于這種類型的所有元素的功能，這些功能的例子有：每個元素必須記錄某些重大事件，每個元素必須為運行期間的外部診斷提供測試點等。在軟件產品線系統中，軟件模板顯得格外重要，因為新元素的引入是一個通用的技術，這種技術用來使產品線架構適應一個特定的產品。

ABSD 方法是遞歸的，且迭代的每一個步驟都是清晰定義的。因此，不管設計是否完成，架構總是清晰的，這有助于降低架構設計的隨意性。

2.1 ABSD 方法與生命周期

圖 1 描述了 ABSD 方法在生命周期中的位置。盡管我們沒有描述一個需求獲取 、 組織或跟蹤的特定方法，但還是假設一個需求階段至少部分地完成，從需求階段（包括功能需求 、 質量和業務需求 、 約束等）獲得了輸出。 ABSD 方法的輸出是三個視圖的概念構件的集合，包括能夠產生每個概念構件的假定 、 軟件模板的集合和那些已經做出的具體實現的決策，我們把具體實現決策當作附加約束來維護。

在 ABSD 方法中，必須記錄所有做出的決策及這些決策的原理，這有利于決策的可跟蹤性和決策評審。

ABSD 方法的輸入由下列部分組成：
（1）抽象功能需求，包括變化的需求和通用的需求；
（2）用例（實際功能需求）；
（3）抽象的質量和業務需求；
（4）質量因素（實際質量和業務需求）；
（5）架構選項；
（6）約束。

下面，我們描述需求階段的假定輸出，即 ABSD 方法的輸入。

2.1.1 抽象功能需求

ABSD 方法假定需求階段的輸出之一是功能需求的抽象描述，包括這些需求的粗略變化的描述。當獲取需求時，考慮所有最終用戶是重要的。

對一個特定系統來說，通常有不同類型的最終用戶。不同的系統管理員（數據庫管理員 、 系統管理員 、 網絡管理員等）都可以是最終用戶。維護工程師也可以是系統的最終用戶?？傊?，一個最終用戶就是當系統運行時使用系統的任何人員。與抽象功能需求相聯系的是對公共需求和與這些需求相關的粗略變化的描述，在設計階段，理解這些需求之間的依賴關系是至關重要的。

我們必須在某種抽象級別上獲取功能需求，產品的詳細需求往往要等具體產品開發完成后才能知道。當詳細需求明確時，抽象功能的獲取為詳細需求提供了分類。

2.1.2 用例

如前所述，用例是一個或多個最終用戶與系統之間的交互的具體表述，在這里，最終用戶既可以是操作人員，也可以是與系統進行交互操作的其他軟件系統。雖然用例很容易找到和創建，甚至可能有成百上千個，但是，因為我們需要分析用例，所以必須限制用例的數量。在架構設計階段，只有重要的用例才有用。我們必須對所創建的用例進行分組 、 設置優先級，以便篩選出最重要的用例，剩下的用例可以在設計階段的任何時候創建。

2.1.3 抽象的質量和業務需求

我們必須對待構建系統的質量和業務需求進行編號，每個質量屬性都包含一個特定的刺激，以及希望得到的響應。質量需求要盡量具體化。

2.1.4 架構選項

對每個質量和業務需求，我們都要列舉能夠滿足該需求的所有可能的架構。例如，如果需求是支持一系列不同的用戶界面，則可能的架構選擇就是把不同的用戶界面分解成不同的構件。又如，如果需求是保持操作系統的獨立性，則可能的架構選擇就是構建虛擬的操作系統層，接受所有的操作系統調用，并解釋之為當前操作系統所能支持。

在這個時候，只需列舉所有可能的選項，而不需要對這些架構選項進行決策，這種列舉取決于設計師的經驗，既可來自某些書籍介紹，也可直接來自設計師本身的實踐。

2.1.5 質量場景

正如用例使功能需求具體化一樣，質量場景使質量需求具體化。質量場景是質量需求的特定擴充。

與用例一樣，質量場景也很容易找到和創建，可以創建很多個。我們必須對質量場景進行分組 、 設置優先級，只需驗證最重要的質量場景。

2.1.6 約束

約束是一個前置的設計決策，設計過程本身包含決策。某些決策可以直接由業務目標導出而無須考慮對設計的影響。例如，如果一個公司在某個中間件產品上投入了大量資金，那么在產品的選擇上就可以不必考慮其他決策。在需求獲取階段，約束主要來自系統的業務目標。

在某些特殊情況下，約束由遺留系統決定。今天，幾乎沒有軟件系統不參考已有系統的，常見的情況是，新老系統同時并存，或者新系統替代老系統，但是必須盡可能重用老系統的功能。在設計階段，雖然這些遺留系統處于被設計系統的外部，但設計師必須考慮遺留系統的特征。也就是說，在某種程度上，遺留系統影響著當前的設計，因此，理解遺留系統的結構和解決問題的技術都很重要。出于商業目的，可能要求重用遺留系統的構件，這種需求就變成了約束。

2.2 基于架構的軟件開發模型

基于架構的軟件開發模型（ Architecture-Based Software Design Model ， ABSDM ）把整個基于架構的軟件過程劃分為架構需求 、 設計 、 文檔化 、 復審 、 實現 、 演化等6個子過程，如圖 2 所示。

2.2.1 架構需求

需求是指用戶對目標軟件系統在功能 、 行為 、 性能 、 設計約束等方面的期望。架構需求受技術環境和架構設計師的經驗影響。需求過程主要是獲取用戶需求，標識系統中所要用到的構件。架構需求過程如圖 3 所示。如果以前有類似的系統架構的需求，我們可以從需求庫中取出，加以利用和修改，以節省需求獲取的時間，減少重復勞動，提高開發效率。

（1）獲取需求

架構需求一般來自三個方面，分別是系統的質量目標 、 系統的業務目標和系統開發人員的業務目標。軟件架構需求獲取過程主要是定義開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足業務上的功能需求。與此同時，還要獲得軟件質量屬性，滿足一些非功能需求。

（2）標識構件

在圖 3 中虛框部分屬于標識構件過程，該過程為系統生成初始邏輯結構，包含大致的構件。這一過程又可分為三步來實現。

第一步：生成類圖。生成類圖的 CASE 工具有很多，例如 Rational Rose 就能自動生成類圖。
第二步：對類進行分組。在生成的類圖基礎上，使用一些標準對類進行分組可以大大簡化類圖結構，使之更清晰。一般地，與其他類隔離的類形成一個組，由泛化關聯的類組成一個附加組，由聚合或組合關聯的類也形成一個附加組。
第三步：把類打包成構件。把在第二步得到的類簇打包成構件，這些構件可以分組合并成更大的構件。

（3）需求評審

組織一個由不同代表（如分析人員 、 客戶 、 設計人員 、 測試人員）組成的小組，對架構需求及相關構件進行仔細的審查。審查的主要內容包括所獲取的需求是否真實反映了用戶的要求，類的分組是否合理，構件合并是否合理等。

必要時，可以在 “ 獲取需求 — 標識構件 — 需求評審 ” 之間進行迭代，在圖 3 中以虛線箭頭表示。

2.2.2 架構設計

架構需求用來激發和調整設計決策，不同的視圖被用來表達與質量目標有關的信息。架構設計是一個迭代過程，如果要開發的系統能夠從已有的系統中導出大部分，則可以使用已有系統的設計過程。軟件架構設計過程如圖 4 所示。

（1）提出軟件架構模型

在建立架構的初期，選擇一個合適的架構風格是首要的。在這個風格基礎上，開發人員通過架構模型，可以獲得關于架構屬性的理解。此時，雖然這個模型是理想化的（其中的某些部分可能錯誤地表示了應用的特征），但是，該模型為將來的實現和演化過程建立了目標。

（2）把已標識的構件映射到軟件架構中

把在架構需求階段已標識的構件映射到架構中，將產生一個中間結構，這個中間結構只包含那些能明確適合架構模型的構件。

（3）分析構件之間的相互作用

為了把所有已標識的構件集成到架構中，必須認真分析這些構件的相互作用和關系。

（4）產生軟件架構

一旦決定了關鍵的構件之間的關系和相互作用，就可以在第2階段得到的中間架構的基礎上進行細化。

（5）設計評審

一旦設計了軟件架構，我們必須邀請獨立于系統開發的外部人員對架構進行評審。

2.2.3 架構文檔化

絕大多數的架構都是抽象的，由一些概念上的構件組成。例如，層的概念在任何程序設計語言中都不存在。因此，要讓系統分析師和程序員去實現架構，還必須得把架構進行文檔化。文檔是在系統演化的每一個階段，系統設計與開發人員的通信媒介，是為驗證架構設計和提煉或修改這些設計（必要時）所執行預先分析的基礎。

架構文檔化過程的主要輸出結果是架構需求規格說明和測試架構需求的質量設計說明書這兩個文檔。生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約。

軟件架構的文檔要求與軟件開發項目中的其他文檔是類似的。文檔的完整性和質量是軟件架構成功的關鍵因素。文檔要從使用者的角度進行編寫，必須分發給所有與系統有關的開發人員，且必須保證開發者手上的文檔是最新的。

2.2.4 架構復審

從圖 4 中我們可以看出，架構設計 、 文檔化和復審是一個迭代過程。從這個方面來說，在一個主版本的軟件架構分析之后，要安排一次由外部人員（用戶代表和領域專家）參加的復審。復審的目的是標識潛在的風險，及早發現架構設計中的缺陷和錯誤，包括架構能否滿足需求 、 質量需求是否在設計中得到體現 、 層次是否清晰 、 構件的劃分是否合理 、 文檔表達是否明確 、 構件的設計是否滿足功能與性能的要求等等。由外部人員進行復審的目的是保證架構的設計能夠公正地進行檢驗，使組織的管理者能夠決定正式實現架構。

2.2.5 架構實現

所謂 “ 實現 ” 就是要用實體來顯示出一個軟件架構，即要符合架構所描述的結構性設計決策，分割成規定的構件，按規定方式互相交互。架構的實現過程如圖 5 所示。

圖 5 中的虛框部分是架構的實現過程。整個實現過程是以復審后的文檔化的架構說明書為基礎的，每個構件必須滿足軟件架構中說明的對其他構件的責任。這些決定即實現的約束是在系統級或項目范圍內做出的，每個構件上工作的實現者是看不見的。

在架構說明書中，已經定義了系統中構件與構件之間的關系。因為在架構層次上，構件接口約束對外唯一地代表了構件，所以可以從構件庫中查找符合接口約束的構件，必要時開發新的滿足要求的構件。

然后，按照設計提供的結構，通過組裝支持工具把這些構件的實現體組裝起來，完成整個軟件系統的連接與合成。

最后一步是測試，包括單個構件的功能性測試和被組裝應用的整體功能和性能測試。

2.2.6 架構演化

在構件開發過程中，最終用戶的需求可能還有變動。在軟件開發完畢，正常運行后，由一個單位移植到另一個單位，需求也會發生變化。在這兩種情況下，就必須相應地修改軟件架構，以適應新的軟件需求。架構演化過程如圖 6 所示。架構演化是使用系統演化步驟去修改應用，以滿足新的需求。

主要包括以下七個步驟：

（1）需求變動歸類首先必須對用戶需求的變化進行歸類，使變化的需求與已有構件對應。對找不到對應構件的變動，也要做好標記，在后續工作中，將創建新的構件，以對應這部分變化的需求。

（2）制訂架構演化計劃在改變原有結構之前，開發組織必須制訂一個周密的架構演化計劃，作為后續演化開發工作的指南。

（3）修改 、 增加或刪除構件在演化計劃的基礎上，開發人員可根據在第一步得到的需求變動的歸類情況，決定是否修改或刪除存在的構件 、 增加新構件。最后，對修改和增加的構件進行功能性測試。

（4）更新構件的相互作用隨著構件的增加 、 刪除和修改，構件之間的控制流必須得到更新。

（5）構件組裝與測試通過組裝支持工具把這些構件的實現體組裝起來，完成整個軟件系統的連接與合成，形成新的架構。然后對組裝后的系統的整體功能和性能進行測試。

（6）技術評審對以上步驟進行確認，進行技術評審。評審組裝后的架構是否反映需求變動，符合用戶需求。如果不符合，則需要在第2到第6步之間進行迭代。

（7）產生演化后的架構在原來系統上所作的所有修改必須集成到原來的架構中，完成一次演化過程。