構件分層元數據對象參考模型的設計

摘要:在概述構件元數據的基本定義基礎上，引入了分層元數據對象的概念，將其分為描述性元數據和操作性元數據兩種類型，進一步對其中的具體內容按照層次概念進行了詳細描述，并給出了其形式化定義#65377;基于此，用UML的類圖給出了構件元數據對象的形式化描述，并結合構件使用方對元數據系統的需求，給出了一個分層元數據系統的結構框架#65377;

關鍵詞:構件; 構件集成測試; 構件元數據; 統一建模語言; 類圖

中圖分類號:TP311.12文獻標志碼:A

文章編號:1001-3695(2007)10-0282-04

由于構件開發方和構件使用方之間信息的缺乏使得構件在集成到具體應用環境時構件的可靠性#65380;安全性無法保證，可維護性難以實現[1]#65377;目前，A.Orso等人[2]提出一種使用描述構件信息的元數據來解決這個問題，構件開發方提供有關構件的細節信息，而無須公開源代碼#65377;但是相同的構件可能會應用于不同的應用環境，構件使用方對信息的需求并不相同，因此構件開發方不可能提供滿足所有構件使用方要求的信息#65377;特別是有一些信息，如數據依賴性或復雜性度量，這些數據計算起來代價昂貴，還有構件以外的相關文檔以及新版本構件對舊版本所作的修改#65377;上述這些信息必須在代碼外提供[3]#65377;現有的構件標準和環境，包括DCOM#65380;企業JavaBeans以及.NET，已經將元數據應用于構件，提供一些附加信息#65377;目前可用的元數據還局限在編譯#65380;運行#65380;類型檢查以及設計用戶化的信息#65377;可將這些信息進行擴展應用于特定任務中，但是不同的元數據目前僅僅解決有限范圍內的軟件工程問題[4，5]#65377;

本文針對上述問題，提出了分層元數據對象的概念，將元數據分為描述性元數據和操作性元數據兩部分(前者描述構件的靜態信息;后者描述其操作信息)，以分層元數據對象形式封裝在一起，供構件使用方在將構件集成到應用程序中實施集成測試時使用#65377;針對構件的特性，給出了描述性元數據和操作性元數據的一般性框架;結合上述框架給出其UML的類圖表示，并進一步將設計的元數據對象組合在一起以元數據系統形式提供給構件使用方使用，以保證構件使用方實施集成測試的效率#65377;

1分層元數據對象參考模型

定義1元數據指的是描述數據的數據，用于描述創建#65380;構造和運行一個構件所需的信息，這些信息不在源代碼中或是二進制代碼中#65377;一般來說，由構件開發方給出相應的元數據供構件使用方在集成該構件時使用，以便提高集成測試的效率#65377;構件的元數據為構件使用方提供所需詳細程度的信息#65377;根據其應用范圍和環境條件的不同，元數據的內容也不盡相同#65377;

A.Orso等人[2]引入的元數據主要包括測試度量#65380;以常量表示的前置和后置條件#65380;數據流和控制流表示，以及屬性#65380;方法和約束列表#65377;文中用C語言實現了一個很簡單的元數據框架#65377;但是所提供的功能缺乏通用性，僅僅提供了一維信息，隨著構件復雜度的提高，這樣的元數據模式顯然無法滿足復雜度不斷增加的構件開發需求#65377;

元數據應用在數據庫時強調標準格式和建立，并采用關系數據庫概念，建立元數據系統#65377;其中每個元數據項表示為單個記錄或XML文檔#65377;但是在實際實現中發現元數據格式的標準化是很困難的，因為單個標準對于應用范圍非常廣泛的構件可能不合適，如單個元數據標準無法同時描述可用于地理信息系統和通用信息系統的構件[6]#65377;

考慮到上述原因，本文根據構件應用的特點以及構件元數據的一般功能和需求，將其分為描述性元數據和操作性元數據#65377;具體使用時，引入面向對象思想，將這兩種元數據封裝在一起，構成一個元數據對象，還可以對該對象進行操作，直接進行應用，如圖1所示#65377;

圖1說明了元數據對象的框架#65377;描述性元數據包括對構件屬性的一般性描述，包含構件使用方在集成到應用環境中所需的靜態信息，描述或標志構件內容和外觀特征#65377;本文根據構件所具有特性[7~10]，將描述構件靜態特性的描述性元數據按照標志#65380;應用#65380;成熟性#65380;變更和質量保證五個層次進行劃分，每一層次包含若干屬性的集合#65377;

操作性元數據包括構件集成到應用環境中可以直接運行的元數據，可方便地實現構件與應用環境的動態交互和集成，而且可以實現跨平臺交互#65377;操作性元數據的具體內容要根據構件所完成的相關操作或任務來確定#65377;本文根據構件的一般特點[11，12]將操作性元數據分為三個層次，即輸入/輸出#65380;運行系統需求和遠程操作#65377;

在上述基礎上，給出分層元數據對象的形式化定義如下:

1.1描述性元數據的一般性框架

根據定義2，下面給出描述性元數據的一般性框架，構件使用方在使用時根據自己的實際情況和具體需求可以進行相關減裁#65377;具體內容如表1所示#65377;

1.2操作性元數據的一般性框架

有關操作性元數據的類別#65380;含義和具體內容的一般性框架如表2所示#65377;具體在使用這些元數據時要根據構件的實際運行環境進行適當的修改#65380;增加和減裁#65377;

表1和2在對構件各種特性進行匯總的基礎上，給出了一個元數據參考模型，使用方在具體使用時根據不同的應用環境以及對構件信息詳細程度的需求分層次地給出元數據的相關信息#65377;

2分層元數據對象參考模型的UML類圖表示

根據上面給出的分層元數據的一般性框架描述，設計了一個構件分層元數據參考模型#65377;圖2給出了其UML類圖的表示形式#65377; 

圖2中，構件涉及到版本問題，因此引入version類用于表示構件版本信息和對這些版本所作的修改信息#65377;其中:number表示版本號;description表示對修改所進行的相關描述;releaseDate表示版本發行的時間;owner表示構件開發方的相關信息;reference表示該構件版本所有的文檔鏈接#65377;引入component類用于保存構件的通用信息和功能，包括name#65380;source#65380;purpose，含義與表1列出的相同#65377;

圖中設計了functional和nonfunctional類來給出該構件版本的功能和非功能需求#65377;每個構件必須集成到各個應用程序中，因此設計了reusability類描述構件所集成的應用程序特性#65377;構件的使用分成兩類，一類是基于規范的，構件開發方提供相應的規范;一類是構件開發方提供構件的源代碼#65377;據此，為基于規范的構件設計了specification document類#65377;其中包含name和developmentTool用于說明規范文檔的名稱和相應的開發工具(如rational rose)，用diagram和text類來分別說明以圖和文本形式給出的規范#65377;為基于實現的構件設計了implementation類，用sourcecode和execuable屬性分別表示是否提供源代碼和可執行代碼，還用相關屬性描述實現構件的基本特點#65377;Testinformation類描述了構件開發方對構件實施單元測試的信息，包括測試名稱#65380;標志#65380;描述和環境等#65377;Documentation類用來描述構件的文檔，有關構件的接口信息則在interface類中給出#65377;接口所提供的方法在method類中給出，其中涉及到parameter類，而returnparameter類則描述了返回參數的信息#65377;

圖2根據構件的基本特點給出設計，具體使用時要進行適當減裁和修改，以適用于不同類型的構件#65377;對于每個元數據，使用圖#65380;表和文本的混合方式描述適用于該構件中的具體數據內容，對于特定領域的構件，其框架不盡相同#65377;

3分層元數據系統的構造

A.Orso等人給出了元數據的表示和存儲，其表示具有很大的靈活性，表示形式為類型/子類型#65377;文中用C語言實現了一個自檢查程序的元數據，簡單易用#65377;David等人[14]給出了以@oms開頭來標志元數據的方法，將元數據分成構件元數據和屬性元數據#65377;前者描述一些構件的基本屬性，如版本號#65380;日期#65380;相關參考等信息;后者描述構件中每個公共屬性，包括屬性的附加信息#65380;數據約束#65380;數據流和缺省值等#65377;在執行構件測試的過程中，依據這些元數據生成輸入數據，使用隨機的數據生成程序產生測試數據#65377;在此基礎上，依據給定的元數據檢查輸出數據#65377;上述兩種方法將給出的元數據與相應的構件附在一起，構件使用方在使用時將這些元數據生成相應的文檔#65377;本文在此基礎上，借鑒元數據在數據庫中的具體應用，構造實現了元數據系統的概念#65377;

3.1元數據系統的需求

從構件開發方的角度來看，元數據系統必須滿足如下基本需求:

a)構件在編譯#65380;連接以及應用導入和執行時，構件開發期間的任何時候可創建#65380;訪問或修改與該構件相關的元數據;b)系統必須能進行擴展，能夠增加新的元數據;

c)系統必須能使得有關的構件開發方能訪問和修改相關的元數據;

d)系統必須與程序語言#65380;硬件結構和中間具體實現無關;

e)當構件版本發生變化，從而有關該構件的元數據要進行版本控制，建立版本信息，系統必須有相應的通知機制通知相關的應用程序，即建立合理的通知機制;

f)構件所集成的應用程序必須能通過適當的方式訪問當前的元數據值;

g)系統必須建立適當的查詢機制滿足不同構件使用方對構件信息的需求;

h)系統必須提供標準的方法記錄和存儲不同的元數據#65377;

根據不同的構件類型可能還有其他具體需求#65377;

從構件使用方的角度來看，元數據系統必須具有如下功能:

a)方便的元數據訪問機制#65377;源代碼對于構件使用方來說是未知的，因此在集成應用程序時所需的一些分析和測試數據必須能從元數據中獲取，如構件開發方提供的數據流分析結果，以及代碼依賴和控制關系計算等#65377;

b)給出構件開發方對構件的測試結果#65377;構件和用戶應用程序可能是以不同的語言實現的，因此基于用戶應用程序的實現語言的分析工具不能對所集成的構件進行測試和分析#65377;

c)系統應提供特定的配置項，使得不同的應用程序可以根據元數據的信息來選擇構件的功能項#65377;

3.2分層元數據系統的一般性框架

在構件集成到不同的應用環境，或是已經使用的構件版本發生變化，要對相應的元數據進行修改時，由于復雜性度高的構件，需要構造相應的元數據系統，提供給構件使用方，方便構件使用方的管理和操作#65377;本文在對元數據系統進行相關需求分析的基礎上，構造了一個分層元數據系統的結構，如圖3所示#65377;

圖3中，所有基于元數據的構件均繼承了一個分層元數據對象(1.1和1.2節中描述)#65377;通過元數據對象的元數據接口，元數據構件聚合了訪問元數據和根據元數據控制構件本身的功能#65377;構件開發方通過構造相應的元數據對象，形成有關的元數據定義，然后可利用成熟的關系數據庫技術建立相應的元數據庫#65377;構件使用方通過建立一致的元數據管理模塊對元數據實現訪問#65380;存取操作#65377;這樣不僅實現了構件的大粒度重用，而且給用戶對構件在一定程度上進行控制的權力#65377;用戶可以按照各應用程序的特殊要求通過定義不同的元數據，從而可以在使用階段改變構件的屬性#65380;行為以及表現方式等，大大增加構件的靈活性#65380;延長了構件的生存周期，加強了構件在不同領域環境中的適應性#65377;

4結束語

基于構件的軟件開發技術是目前常用的軟件開發方法，但是如何使構件使用方有針對性地實施有效的集成測試以保障構件系統質量和可靠性成為重要的研究方向#65377;基于此，本文引入了分層元數據對象的概念，詳細描述了分層元數據對象的具體內容和實現框架，用UML類圖的形式化方法描述其含義，在此基礎上構造了一個分層元數據系統#65377;與Orso在文獻[2]中給出的元數據相比，本文所給出的元數據具有更好的靈活性，更具通用性，適用于更復雜的構件信息描述#65377;篇幅所限，本文未列出相關比較結果，如何針對具體應用程序進行減裁則是需要進一步研究的內容#65377;

參考文獻:

[1]VAOS M. Certifying offthe shelfcomponents[J]. IEEE Computer， 1998，31:34-45.

[2]ORSO A， HARROLD M J， ROSENBLUM D. Component metadata for software engineering tasks[C]//Proc of the 2nd International Workshop on Engineering Distributed Objects(EDO 2000). Davis:[s.n.]， 2000:129144.

[3]VOAS J. The challenges of using COTS software in componentbased development[J]. IEEE Computer， 1998，31(6):44-45.

[4]ORSO A， HARROLD M J， ROSENBLUM D， et al. Using component metacontent to support the regression testing of componentbased software[C]//Proc of IEEE International Conference on Software Maintenance (ICSM’01). Florence:[s.n.]， 2001:716-725.

[5]HARROLD M J， LIANG D， SINHA S. An approach to analyzing and testing componentbased systems[C]//Proc of Workshop on Testing Distributed Componentbased Systems. 1999:45-51.

[6]TSOU M H， BUTTENFIELD B P. C/S components and metadata objects for distributed geographic information services[C]//Proc of the GIS/LIS’98. Fort Worth， Texas:[s.n.]， 1998:59-75.

[7]BRERETON P， BUDGEN D. Componentbased systems: a classification of issues[J]. IEEE Computer， 2000，33(11):54-62.

[8]YACOUB S， AMMAR H. Characterizing a software component[C]//International Workshop on Componentbased Software Engineering. Los Angeles， CA:[s.n.]， 1999:34-42.

[9]CARNEY D， LONG F. What do you mean by COTS?Finally， a useful answer[J]. IEEE Software， 2000，17(2):83-86.

[10]SPARLING M. Lessons learned through six years of componentbased development[J]. Communications of the ACM， 2000，43(10):47-53.

[11]BROWN A W， SHORT K. On components and objects: the foundation of componentbased development[C]//International Symposium on Assessment of Software Tools and Technologies. Pittsbuggh， PA: IEEE Press， 1997:112121.

[12]SAMETINGER J. Software engineering with reusable components[M]. New York: SpringerVerlag， 1997:54-66.

[13]CAMPBELL D P， COTTEL D M， et al. The PCA metadata system[R].[S.l.]: Georgia Institute of Technology and Space and Naval Systems Center， 2004:3-8.

[14]DAVID O， MARKSTROM S L， ROJAS K W， et al. The object modeling system[M]//AHUJA L， MA L， HOWELL T A. Agricultural system models in field research and technology transfer.[S.l.]:Lewis Publishers， CRC Press LLC， 2002:317-331.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”