組件系統(tǒng)接口匹配識別方案和應用

陳宏君，王國棟

(南京南瑞繼保電氣有限公司，江蘇 南京 211102)

組件系統(tǒng)接口匹配識別方案和應用

陳宏君，王國棟

(南京南瑞繼保電氣有限公司，江蘇 南京 211102)

在平臺化、組件化的開發(fā)背景下，文中提出一種組件系統(tǒng)接口匹配識別方案。該方案首先在版本描述文件中記錄組件的當前版本、父版本、兼容標記，并填寫所依賴組件的工作版本，之后在集成配置文件中設置各個組件的工作版本。打包工具通過分析組件版本描述文件和集成配置文件，構(gòu)建單個組件的版本演化樹，根據(jù)各個組件版本演化樹和組件間依賴的工作版本，構(gòu)建組件系統(tǒng)依賴圖，將組件系統(tǒng)的版本匹配拆分為判斷各個組件被其他組件所依賴的工作版本是否匹配。如果各個組件在系統(tǒng)內(nèi)都是匹配的，則整個組件系統(tǒng)是版本匹配的。

組件系統(tǒng);版本樹;接口匹配;組件依賴

0 引 言

在平臺化軟件開發(fā)和使用周期內(nèi)，由于面向的應用領(lǐng)域高度復雜，往往存在增強功能、優(yōu)化性能、修復缺陷等需求，這要求軟件系統(tǒng)具有較強的適應能力，以便于開發(fā)人員能快速集成。基于組件的軟件開發(fā)方法可減少軟件開發(fā)成本和加快開發(fā)進度,故組件化的開發(fā)得到了廣泛應用[1-5]。復雜、大規(guī)模軟件體系結(jié)構(gòu)出現(xiàn)網(wǎng)絡化、層次化、分布式的發(fā)展態(tài)勢，軟件規(guī)模擴大化，同構(gòu)、異構(gòu)模塊存在復雜的交互協(xié)同方式，軟件的兼容性問題也日益突出[6]。嵌入式和上位機軟件的組件模型在建模過程中可包括3類[7]：源碼組件(編譯時組件)、二進制代碼組件(鏈接時組件)、可執(zhí)行代碼組件(運行時組件)。基于組件進行系統(tǒng)組合時，存在一些交互活動的序列不匹配而導致組合行為不兼容的情況[8-14]。某個組件升級后，應用人員進行集成打包時，存在如下問題或需求：

(1)個別組件升級時，是否其他組件也需配套升級，能否可選升級個別組件；避免所有功能都需完整測試一遍；

(2)如何判斷部分升級時，功能接口是匹配兼容的；

(3)某個組件新增的功能，本應用不需要時，是否可保留當前斷面版本，不用升級到最新版本；

(4)是否可跨版本升級。

在平臺化、組件化、模塊化架構(gòu)的開發(fā)模式下，希望在解耦發(fā)布、可選打包、版本匹配方面能有通用的解決方案，實現(xiàn)組件系統(tǒng)的快速可靠集成。

文中介紹了版本演化樹,構(gòu)建了組件系統(tǒng)依賴圖，設計了組件系統(tǒng)接口匹配識別方案。

1 組件概念

組件(package/component)是可獨立發(fā)布的二進制單元。組件是1個黑盒子，對外的接口主要是API功能和端口，其中API是組件對外提供的功能，端口表示組件內(nèi)部調(diào)用外部其他組件功能的函數(shù)[2]。圖1是一種組件模型。

圖1 組件模型

組件、總線、接口是組件系統(tǒng)的三元組，組件本質(zhì)是程序，可由界面、函數(shù)、數(shù)據(jù)等組成，它實現(xiàn)某種功能，并通過預定義的接口連接到總線上。總線是一個宿主總控程序，負責組件之間的互操作和通信。接口負責組件的設置、啟動、初始化、注銷和數(shù)據(jù)通信等工作。在對組件的接口定義了統(tǒng)一的規(guī)范后，系統(tǒng)投入運行時，用戶可以根據(jù)自己的需要通過接口集成到系統(tǒng)中，或從系統(tǒng)中卸載，而宿主程序和軟件框架均不用修改。

2 組件系統(tǒng)接口匹配判據(jù)

單個組件基于版本演化信息文件構(gòu)建版本生成樹，按照父節(jié)點-子節(jié)點層次關(guān)系形成N叉樹，從子節(jié)點訪問父節(jié)點路徑需設置兼容、不兼容標志，單個組件內(nèi)兩個版本(A、B)是否兼容的判據(jù)是:從版本A節(jié)點出發(fā)，通過遞歸訪問其若干層父節(jié)點，可構(gòu)成1條連通路徑到版本B節(jié)點，并且該路徑都是可兼容的。

一個系統(tǒng)由N個組件構(gòu)成，各組件之間可能存在版本依賴關(guān)系，則整個系統(tǒng)最多構(gòu)成N*(N-1)/2條依賴關(guān)系。單個組件最多被N-1個組件依賴。則單個組件在系統(tǒng)內(nèi)是否匹配的判據(jù)是：該組件的當前版本和被其他組件依賴的各個版本號之間都是兼容的。如果所有組件在系統(tǒng)內(nèi)都是匹配的，則整個系統(tǒng)是接口匹配能正常工作的。

3 組件版本演化樹

單個組件(模塊)存在版本分支，新版本基于某個舊版本升級開發(fā)，用N叉樹結(jié)構(gòu)描述版本演化過程。將新舊版本映射為子-父節(jié)點，新舊版本之間存在兼容、不兼容的情況。其三元組為<新版本號，舊版本號，兼容標記>，見圖2。

圖2 版本演化樹

版本是否兼容，由開發(fā)者在發(fā)布時標注，如下情況視為兼容：

(1)修改bug,未增加接口、未改變功能行為；

(2)新增可選接口函數(shù)、可選輸入、輸出、參數(shù)。

如下情況視為不兼容：

(1)刪除接口、變量；

(2)修改接口名、變量名、配置方式；

(3)修改了功能行為定義。

其中接口、變量的變化，通過分析對比源文件，詞法分析后，進行特定語義分析，提取出函數(shù)列表和形參列表，可進行智能校驗。當刪除原有接口或形參不一致時，置接口不兼容標記，僅新增接口或接口無變化，置接口兼容標記。對于功能函數(shù)行為的變化，需人工確定是否兼容，故組件版本節(jié)點兼容標志是半自動獲取的，是將自動分析獲取的接口兼容標記和人工設置的功能行為兼容標記進行與操作后得出組件版本間兼容標記。版本演化樹通過讀取版本信息文件構(gòu)建。版本樹形結(jié)構(gòu)定義如下：

structVNode{

Stringcurrent_version; //當前節(jié)點版本

QStringparent_version; //父節(jié)點版本

boolcompatible; //是否和父節(jié)點兼容

VNode*parent; //父節(jié)點指針

QListchild_list; //第1層子節(jié)點

};

4 組件系統(tǒng)依賴圖

一個系統(tǒng)內(nèi)的組件通常存在版本、功能依賴關(guān)系，組件之間能正常協(xié)同運行，依賴其他組件有合適匹配的版本(最小工作版本)。將系統(tǒng)的版本匹配拆分為各個組件被要求依賴的版本是否兼容的問題。通過讀取組件依賴配置文件，可形成單個組件被要求的工作版本序列，根據(jù)版本兼容演化規(guī)則，如果單個組件的版本序列是隸屬于1個可兼容分支，并可演化到當前版本，則進行版本歸并，判斷為單個組件滿足其他組件的依賴要求。如果所有組件都滿足其他組件的依賴要求，則整個系統(tǒng)是版本匹配的。

以圖3為例，當前系統(tǒng)由3個組件構(gòu)成，分別為V1.3版本的Master,V1.2版本的Slave,V1.2版本的IEC103。而V1.3的Master需要的其他組件工作版本為V1.1的Slave。V1.2版本的Slave需要V1.3的Master配合。V1.2的IEC103依賴V1.0的Slave和V1.2的Master。

圖3 組件間版本配合依賴關(guān)系示意圖

對每個組件:

(1)Master被其他組件依賴的版本序列為:V1.3、V1.2，當前打包版本為V1.3；

(2)Slave被其他組件依賴的版本序列為：V1.1、V1.0，當前打包版本為V1.2；

(3)IEC103未被其他組件依賴，當前打包版本為V1.1；

(4)則版本匹配的問題拆分為3個進程各自的版本序列是否是可兼容的；假如4個組件的版本演化樹如圖4所示，則可得出該系統(tǒng)的組件之間是版本接口匹配的結(jié)論。

圖4 系統(tǒng)的兼容匹配轉(zhuǎn)換為各個組件的

5 版本描述和集成文本

定義組件版本描述文件格式，組件開發(fā)人員按照格式填寫對應組件版本信息。組件發(fā)布時，開發(fā)人員同步提供組件版本描述文件。記錄當前版本、父版本、兼容標記，并保留組件開發(fā)歷史版本的記錄和隸屬關(guān)系，如果依賴其他組件，則須填寫外部組件的工作版本信息。版本描述文件示例如下：

[Key=IEC103Current=1.1]

[VersionChild=1.1,Parent=1.0,Compatible=1]

[DependKey=MASTER,ReqV=1.3] [DependKey=SLAVE,ReqV=1.2]

[VersionChild=1.0,Parent=1.0,Compatible=1]

其中，Key填寫組件名，Current填寫組件當前版本；Child填寫子版本、Parent填寫父版本，Compatible填寫兼容標志；DependKey填寫依賴的外部組件名，ReqV填寫依賴的外部組件工作版本。單個組件發(fā)布新版本時，需更新組件版本描述文件，并保留歷史版本的描述信息。

集成人員填寫組件系統(tǒng)集成配置文件。不同應用人員，所需集成的組件、版本可能不同，通過組件系統(tǒng)集成配置文件，描述該系統(tǒng)所包括的各個組件名字、工作版本。集成配置文件示例如下：

Key=MASTERVersion=1.3

Time=2014-12-06_16:29:59Crc=8F6DE121

Key=SLAVEVersion=1.2

Time=2014-11-11_20:27:19Crc=2E9F6B30

Key=IEC103Version=1.1

Time=2014-10-22_10:25:36Crc=6A5BC31E

其中,組件名Key、組件工作版本Version是關(guān)鍵信息；Time是組件編譯形成時間；CRC是組件的校驗碼。

6 具體實現(xiàn)步驟

打包工具通過讀取version.txt文件、各組件版本描述文件，可構(gòu)建組件的版本演化樹、組件之間依賴版本、組件的工作版本序列，并按照規(guī)則得出當前打包的組件之間接口是否匹配的結(jié)論。

關(guān)鍵步驟如下：

第一步：定義組件版本描述文件，在版本描述文件中記錄組件當前版本、父版本、兼容標記，并保留組件開發(fā)歷史版本的記錄和隸屬關(guān)系，若該組件依賴其他組件，則須填寫所依賴組件的工作版本。

第二步：定義組件系統(tǒng)集成配置文件，在該文件中定義所挑選的各個組件名、對應的工作版本。

第三步：分析各個組件版本描述文件，構(gòu)建單個組件的版本演化樹，并判斷單個組件的任意2個版本是否兼容。用N叉樹結(jié)構(gòu)描述組件版本演化過程，將新-舊版本映射為子-父節(jié)點，其三元組為<新版本號，舊版本號，兼容標記>。從子節(jié)點訪問父節(jié)點路徑需設置兼容、不兼容標志，則單個組件內(nèi)兩個版本(A、B)是否匹配的判據(jù)是:從版本A節(jié)點出發(fā)，通過遞歸訪問A節(jié)點的多層父節(jié)點，可構(gòu)成1條連通路徑到版本B節(jié)點，并且該路徑都是可兼容的。

第四步:分析組件集成配置文件，并根據(jù)各個組件版本演化樹和組件間依賴的工作版本，構(gòu)建組件系統(tǒng)依賴圖，將組件系統(tǒng)的版本匹配拆分為判斷各個組件被依賴的工作版本是否匹配。按照第2節(jié)的整體設計思路進行判斷。

如圖5所示,調(diào)用版本匹配判斷檢測工具，組件開發(fā)人員定義組件版本描述文件，集成人員定義組件系統(tǒng)配置文件，通過工具導入各個組件版本描述文件和集成配置文件，工具基于第三步、第四步原理進行分析后，得出組件系統(tǒng)版本是否匹配的結(jié)論。

圖5 打包時版本匹配的處理流程

7 結(jié)束語

基于文中提出的方案，組件集成人員基于版本匹配工具，能快速得出組件系統(tǒng)是否匹配的結(jié)論，加快了集成的速度，降低了由于版本不匹配的配置風險。該發(fā)明已經(jīng)在電力系統(tǒng)控制保護平臺的嵌入式組件系統(tǒng)、上位機可視化編程配置組件系統(tǒng)的集成時進行了應用，結(jié)果表明開發(fā)集成效率得到了顯著提高。

[1] 陶傳奇,李必信,JerryGao,等.基于模型的構(gòu)件軟件修改影響分析[J].軟件學報,2013,24(5):942-960.

[2] 袁偉民,左 春.基于樣本程序的領(lǐng)域開發(fā)平臺的研究與實踐[J].計算機工程與設計,2010,31(18):3979-3982.

[3] 丁 博,王懷民,史殿習.構(gòu)造具備自適應能力的軟件[J].軟件學報,2013,24(9):1981-2000.

[4] 周曉鋒,馬志強,劉馨月.一種基于組件的軟件開發(fā)方法[J].信息技術(shù)與標準化,2005(9):35-38.

[5] 張 馳.軟件組件接口擴展技術(shù)研究[J].微電子學與計算機,2007,24(8):35-37.

[6] 王 博,白曉穎,賀 飛,等.可組合嵌入式軟件建模與驗證技術(shù)研究綜述[J].軟件學報,2014,25(2):234-253.

[7] 何鵬飛,何 平,張松陽,等．組件技術(shù)在嵌入式系統(tǒng)中的應用[J].計算機系統(tǒng)應用,2014,23(6):220-223.

[8] 鄭曉梅,胡晨駿,李 剛,等.基于MDE的AADL構(gòu)件組合兼容的方法[J].計算機工程與設計,2014,35(5):1862-1867.

[9] 孫小兵,李必信,陶傳奇.基于LoCMD的軟件修改分析技術(shù)[J].軟件學報,2012,23(6):1368-1381.

[10] 史浩輝,何 煒.基于構(gòu)件的指控軟件復用[J].計算機技術(shù)與發(fā)展,2011,21(2):159-161.

[11]TaoCQ,LiBX,SunXB.AhierarchicalmodelforregressiontestselectionandcostanalysisofJavaprograms[C]//ProcoftheAsiaPacificsoftwareengineeringconf.Sydney:IEEEComputerSociety,2010:290-299.

[12]LinL,ProwellSJ,PooreJH.Theimpactofrequirementschangesonspecificationsandstatemachines[J].JournalofSoftwarePracticeandExperience,2009,39(6):573-610.

[13]ParkS,BaeDH.Anapproachtoanalyzingthesoftwareprocesschangeimpactusingprocessslicingandsimulation[J].JournalofSystemsandSoftware,2011,84(4):528-543.

[14]HassanMO,DeruelleL,BassonH.Aknowledge-basedsystemforchangeimpactanalysisonsoftwarearchitecture[C]//Procoftheresearchchallengesininformationscience.[s.l.]:[s.n.],2010:545-556.

Matching Recognition Scheme for Interface of Component System and Its Application

CHEN Hong-jun,WANG Guo-dong

(NR Electric Co.,Ltd.，Nanjing 211102，China)

With the modular philosophy and developing in platform architecture,a matching recognition scheme for interface of component system was presented.Firstly,the scheme records current version,parent version and compatible tokens of component in the version description file as well as the version information of components depended by the current components,then it sets working version of each component in the integrated configuration file.After all that the packaging tool analyzes the version description file and integrated configuration file of each component to construct version evolution tree of every component,and furthermore establish dependency graph of the component system by analyzing the version evolution tree of each component and the working version depended by every components.Finally split the version matching problem of a whole component system into matching of working version of each component depended by other components.And when every component in the system is matched,the whole component system would be version matched.

component system;version tree;interface matching;component dependency

2015-05-10

2015-08-13

時間：2016-01-26

國家“863”高技術(shù)發(fā)展計劃項目(2015AA050101)作者簡介：陳宏君(1981-)，男，高級工程師，碩士，研究方向為可視化編程軟件和嵌入式軟件。

http://www.cnki.net/kcms/detail/61.1450.TP.20160126.1517.024.html

TP39

A

1673-629X(2016)02-0124-04

10.3969/j.issn.1673-629X.2016.02.028