軟件的可復用性是人們評價一個軟件系統的重要指標。軟件復用是提高軟件生產效率與質量的一種有效途徑，它可以通過軟件中的可復用構件(reusable component)來實現，即通過集成已有的構件來創建新系統。以領域分析為基礎的特定領域復用(Domain-Specific Reuse)是提高軟件復用水平的重要途經之一。將目標集中在一個特定應用領域中實現軟件復用，從構件的開發到構件的存儲與管理都比較容易。本文對結合面向對象、FODA方法和構件化思想的領域分析方法進行了初步探索，提出了構件化的領域分析方法，從而為在軟件開發的前期階段實現構件化開發，更加有效地實現軟件復用提供了指導。

1 相關理論

1.1 軟件復用

軟件復用是指重復使用“為了復用目的而設計的軟件”的過程。軟件復用是在軟件開發中避免重復勞動的解決方案，其出發點是應用系統的開發不再采用一切“從零開始”的模式，而是以已有的工作為基礎，充分利用過去應用系統開發中積累的知識和經驗，如：需求分析結果、設計方案、源代碼、測試計劃及測試案例等，從而將開發的重點集中于應用的特有構成成分。

與軟件復用相關的兩個基本開發活動是面向復用的開發和基于復用的開發，前者是生產可復用構件的過程，后者是利用現有的可復用構件生產新系統的過程。它們分別對應領域工程和應用工程，處理好它們之間的關系，才能實現真正成功的軟件復用。

1.2 領域工程

領域工程是為一組相似或相近系統的應用工程建立基本能力和必備基礎的過程，它覆蓋了建立可復用的軟件構件的所有活動。其中“領域”是指一組具有相似或相近軟件需求的應用系統所覆蓋的功能區域。

領域工程是創建可復用構件的過程，其核心思想是：應用模式領域化，問題抽象通用化，軟件元素重用化，開發過程工程化。實施領域工程的過程可以分為以下三個主要的階段：
(1)領域分析：目標是獲得領域模型。
(2)領域設計：目標是獲得DSSA(特定領域軟件體系結構)。
(3)領域實現：主要任務是依據領域模型和DSSA開發、組織可重用構件。

需要特別指出的是，領域工程的三個基本階段所描述的過程是一個反復的、逐漸求精的過程。在實施領域工程的每個階段中，都可能返回到以前的步驟，對以前得到的結果進行修改和完善，再回到當前步驟，在新的基礎上實施本階段的過程。

1.3 面向特定領域的軟件開發

與領域工程相對的是開發單個應用系統的軟件工程的過程，稱為應用工程。

在應用工程中，軟件開發人員的任務是針對一組特定的需求產生一組特定的設計和實現。與此相對，在領域工程中，領域工程人員的基本任務是對一個領域中的所有系統進行抽象。領域工程的各個階段主要是對應用工程中相應階段產品的抽象，領域工程又對本領域中新系統的開發提供支持。在CBSE思想的指導下，基于構件的應用工程實際上是構件的組裝過程。構件(Component)是指應用系統中可以明確辨識的構成成分。而可復用構件是指具有相對獨立的功能和可復用價值的構件。隨著對軟件復用理解的深入，構件的概念已不再局限于源代碼構件，而是延伸到需求、系統和軟件的需求規約、系統和軟件的構架、文檔、測試案例和數據以及其他對開發活動有用的信息。這些可復用軟件構件通過領域工程獲得，作為應用工程開發的基本元素。

在開發實際的應用系統時，將領域工程與應用工程相結合，可以快速、有效地開發出用戶滿意的系統。兩者相結合的軟件開發模型如圖1所示。

通過以上討論可以看到，在面向領域的軟件開發過程中，領域模型的建立是軟件開發的基礎。當開發同一領域的新系統時，可根據領域分析確定新應用的需求規約，以此來指導貫穿于整個開發的設計與組裝。因此領域分析的成功與否，對今后的開發具有舉足輕重的作用。領域分析的成功復用，可以從更抽象的層次實現軟件復用。

1.4 領域分析

所謂領域分析(DA)就是在系統分析之前，分析、研究有關應用領域特性的活動。它是發現和記錄某個領域各系統的共性和差異的過程，是系統化、形式化、有效復用的關鍵。通過領域分析，相似系統的公共特性將被提取，適用于該領域所有公共的、基本的對象、操作也將被標志出來，并且可通過定義模型描述它們之間的關系。領域分析的目標就是獲得領域模型。領域模型(Domain Model)是領域中各系統的共同需求的描述。它描述了領域內系統需求上的共性。

1.4.1 FODA方法與特征模型

FODA對領域分析過程進行了完整的描述，特征概念是FODA方法的核心。所謂特征是指系統中的屬性和特點，按特征在領域中的可選性及特征間的相互關系可分為三類：

(1)強制性特征：必須被選擇的特征。
(2)可選特征：從0到n個可供選擇的特征。
(3)可替換特征：至少有一個被選擇的特征。

按特征的內容也可分為三類：
(1)功能相關：系統所作的事情。
(2)環境相關：系統是如何被使用的，變化點的原因。
(3)表示相關：系統信息是如何被用戶所觀察的或者是如何被相關應用所獲得的。

特征模型通過使用抽象和細化的機制對領域中不同應用的所有特征進行了分類，從而提供了關于領域體系結構和可復用構件的高層視圖。特征模型可作為應用開發者的地圖，當應用開發者面對龐雜的Use Case模型或者其他模型時，特征模型提供了關于哪些是可選的、哪些是可合并的信息。

1.4.2 領域Use Case模型和動態模型

領域Use Case模型是RSEB(Reuse-Driven Soft-ware Engineering Business)方法為了表示領域中用戶需求的不同之處對其進行擴展而形成的。但是領域Use Case模型無法詳細地表示出系統工作流程。為了更詳細地描述整個系統對象間的活動，考慮在領域Use Case模型中附加動態模型對工作流進行建模。領域Use Case模型和動態模型采用構件化的思想進行組裝。動態模型可以采用uml的活動圖描述，領域Use Case或單個的活動與活動圖之間通過接口進行連接，并且有明確的標識，從而完整、獨立、詳盡地描述特征模型。在此還特別注意了可變性機制，可變性機制中主要是變化點和變體的表示。變化點是指在Use Case中不同應用之間的不同處理方式或處理對象的一種抽象，而變體是指變化點的一種具體實現方法。

為了領域Use Case模型和動態模型的構件化組裝，在實際應用中定義了這些描述需求的構件接口，接口定義如下：

接口=(Provides，Requires)
其中，Provides為對外提供的功能/服務，Requires為對外要求的功能服務。
Provides=({provideFunction})
Requires=({requiredIncludedFunction}，{requiredExtendedFunction})
需要說明的是，在對外要求的功能/服務中，requiredIncludeFunction是必須滿足的條件，requiredExtendFunction是可能滿足的條件，從而增加了構件的靈活性和可變性。

2 構件化的領域分析方法

領域分析是提取構件和建立體系結構的關鍵。依據面向對象、FODA中特征的概念以及CBSE方法的一些思想，進行領域分析有以下幾個步驟：

(1)建立領域邊界模型：目的是定義領域的范圍。
方法是，從待分析領域中確定包含哪些應用，表示出本領域系統的邊界；從這些應用中找出所有與本領域進行交互的人或領域，并表示出它們的通用職責。為了確定領域的范圍，可以根據領域知識用類似于高層抽象用例圖的形式來表示。

(2)建立特征模型：目的是識別領域中應用的共同特征和可變特征。
方法是，在實際建模中利用開發的原型或現存系統尋找本領域中的通用功能和可選功能，抽象表示成強制性特征和可選的特征；然后找到相同功能的不同實現方法, 用可替換特征表示；最后考察模型中的特征是否可以被進一步分解為子特征，從而形成特征模型。

(3)建立領域Use Case模型和動態模型：目的是將領域內的特征描述完整化、獨立化，并且具有可適應性和可標識性。通過此步可以描述整個領域的業務處理。

方法是，選擇特征模型中強制性特征、可替換特征以及一些出現頻率比較高的可選特征作為通用功能；將具有相似功能或者操作同一對象的功能組成一個Use Case，在組成一個Use Case時也要考慮復用力度的問題，根據復用的力度選擇Use Case的規模；強制性特征、可選特征和可替換特征分別利用uml中的包含(include)、延伸(extend)和實現(realize)關系予以表示，從而映射到Use Case模型中，并且定義其接口；對于相對具體的Use Case，利用動態模型描述隨時間發生的活動和參與的對象，并且定義接口與其描述的Use Case模型連接，對于某些活動可以繼續定義動態模型并通過接口進行組裝。

(4)建立對象模型：目的是抽象出主要的對象和類，描述領域中對象和類的靜態關系，為下一步體系結構的建立打下基礎。

方法是，將動態模型中的對象與領域Use Case模型中的名詞相結合建立對象模型；把相同或相似的對象進行合并；最后再用使用、繼承、參數化等機制實現變體。

綜上所述，整個分析過程分為以上四步進行，但這四步不是線性的，是并行和迭代的。它是對以上模型不斷精化的過程，可以分成幾個周期不斷循環進行，直至得到滿意的領域模型。在此過程中，還有一個將所得模型構件化提交構件庫的階段，在此不作討論。

3 應用分析

　　隨著科學技術的不斷發展，各高校、科研院所等單位的項目負責人在進行項目開展時，往往需要各部委等的基金資助，以保證項目的正常進行。如此多的項目基金的管理就相對地形成了一個基金管理領域。在這個領域中，利用基金管理系統可以大大提高基金機構管理的效率，實現辦公自動化，以節省人力、物力和財力。通過領域工程，建立起基金管理領域模型和統一的構架以及對實現有用的構件，可指導領域內所有應用系統的開發。根據上述領域分析方法，我們在領域分析階段將其應用于基金管理的模型開發中。

依據筆者對基金管理領域知識的了解并結合相關的基金管理系統，對基金管理系統進行領域邊界分析，確定基金管理領域的領域邊界模型。基金管理機構內一般包括基金管理者和維護系統運行的管理人員，基金管理機構外則涉及到基金申請者和評審專家。系統內外的參與者和領域的交互，就構成了基金管理系統的領域范圍，領域邊界模型如圖2所示。

然后將基金管理系統所具有的功能特征(如專家評審、申請管理、專家管理和撥款等)、環境特征(如不同的基金管理機構提供不同的基金資助)和表示特征用特征模型表示出來。在這個模型中包括所有基金管理系統都具有的強制性特征(如專家管理、申請管理、撥款等)， 也包括可選特征(如并不是所有的基金管理機構都提供項目總結管理)，還包括可替換特征(如評審方式可以是在線評審也可以通過郵件發送文檔的方式評審)。特征模型(部分)如圖3所示。

再根據以上特征模型中的功能特征抽取出通用功能，包括用戶登錄、添加活動、修改活動、瀏覽信息、查詢信息、統計打印信息、分配專家、專家評審等，將其用Use Case描述，如圖4所示，并且還可以插入活動圖。下面給出評審管理的部分描述，此處選用了專家評審這一用例，其中評審是變化點，它有2個變體(在線評審和郵件發送文件)。

其接口定義為：
Provides：
function setopinion( )
Requires：
Include：
Extend：function onlinegetinfor( )
將在線評審用例繼續用活動圖描述，在這個活動圖中，對象object就是評審對象。
其接口定義為：
Provides：
function onlinegetinfor( )
Requires：
由上可知，通過接口的定義可以建立動態模型和Use Case模型之間的描述關系，如圖5所示，從而更加具體地將特征模型映射到領域Use Case模型中。

接下來由面向對象方法及領域Use Case模型和動態模型得到對象模型，它描述了本領域中重要的對象和它們之間的關系。對象模型是領域應用系統的靈魂，通過對象之間的交互形成具體的應用系統的體系結構。從以上工作中可得到基金、申請者、專家、申請、資助項目、評審和單位七個類，變化點和變體可通過泛化在類圖中表示。對象模型如圖6所示。

至此建立了整個領域的領域模型，同時利用uml半形式化地描述了領域需求。根據領域模型，可以進一步建立DSSA，進行軟件的下一步開發，將所得的可復用的構件加入構件庫。在進行具體應用系統的開發時，通過提取可復用構件和開發新的專用構件，可完成整個應用系統的組裝。

本文結合在基金管理領域中進行領域分析的實踐，對構件化的領域分析過程進行了說明，該方法在建立特征模型的基礎上，利用領域Use Case模型和動態模型構件化地分析了領域需求，并且表示了領域中對不同應用的不同處理方式。這樣將可在軟件開發的前期階段實現構件化開發，有助于重用者更加方便有效地進行設計、實現階段的構件化開發，實現軟件開發的有效復用。