田 剛，何克清，孫承愛，崔煥慶，彭珍連，3

（1.山東科技大學(xué)信息學(xué)院，山東 青島266590；2.武漢大學(xué)軟件工程國(guó)家重點(diǎn)實(shí)驗(yàn)室，湖北 武漢430072；3.湖南科技大學(xué)計(jì)算機(jī)學(xué)院，湖南 湘潭411201）

1 引言

軟件演化是指在軟件系統(tǒng)的生命周期內(nèi)軟件維護(hù)和軟件更新的行為和過程。在現(xiàn)代軟件系統(tǒng)的生命周期內(nèi)，演化是一項(xiàng)貫穿始終的活動(dòng)，包括需求演化、設(shè)計(jì)演化、運(yùn)行時(shí)演化等。如何使開發(fā)的軟件能夠在運(yùn)行時(shí)根據(jù)用戶的需求變化實(shí)時(shí)演化，一直是研究的焦點(diǎn)。

網(wǎng)絡(luò)式軟件需求演化建模關(guān)注的問題是如何在重用領(lǐng)域共性需求模型的基礎(chǔ)上，針對(duì)個(gè)性化需求的變化，利用演化建模方法在原始需求的基礎(chǔ)上建立滿足新需求的模型。其中，需要用到的關(guān)鍵技術(shù)包括：支持情景感知的角色－目標(biāo)－流程－服務(wù)RGPS（Role-Goal-Process-Service）需求元模型框架［1］；基于本體-RGPS O-RGPS（Ontology-RGPS）的領(lǐng)域模型庫；支持人網(wǎng)交互模式，捕獲用戶個(gè)性化需求的面向服務(wù)的需求獲取語言SORL（Services-Oriented Requirement Language）［2］。

2 軟件演化研究

面向方面和基于反射結(jié)構(gòu)的軟件演化方法是當(dāng)前實(shí)現(xiàn)軟件演化的兩大主流方法。

2.1 面向方面的演化方法

面向方面的軟件演化方法的基本思想是將方面織入到需要演化的軟件系統(tǒng)中，快捷地支持軟件演化。Cazzola W［3］指出了在代碼演化中如何應(yīng)用方面，使用UML模型定義了連接點(diǎn)模型來增進(jìn)方面的可重用性。盡管該方法對(duì)于程序員來說清楚易懂，但是如何將高層的設(shè)計(jì)信息轉(zhuǎn)換到低層的代碼和如何保證轉(zhuǎn)換的一致性仍然是未解決的難題。Anis Charfi［4］提出了一種稱為 AO4BPEL的語言，通過擴(kuò)展BPEL并在Web服務(wù)執(zhí)行過程中動(dòng)態(tài)地織入一些新的方面，實(shí)現(xiàn) Web服務(wù)組合的演化。這種方法同本文的方法類似，但是其切入點(diǎn)的定義并不是基于RGPS需求元模型，因此無法和本文方法無縫對(duì)接。

2.2 基于反射體系結(jié)構(gòu)的軟件演化方法

反射系統(tǒng)基層描述系統(tǒng)被期望進(jìn)行的計(jì)算；元層描述系統(tǒng)怎樣執(zhí)行計(jì)算。運(yùn)行時(shí)的系統(tǒng)作為基層，元層管理演化的規(guī)則、演化的操作以及演化事件的截取等。Cazzola W在文獻(xiàn)［5，6］提出了一種反射式中間件 RAMSES（Reflective and Adaptive Middleware for Software Evolution of Systems）。它能夠根據(jù)系統(tǒng)的設(shè)計(jì)信息在運(yùn)行時(shí)改變基層系統(tǒng)的結(jié)構(gòu)和行為，從而實(shí)現(xiàn)實(shí)時(shí)的演化。Edmond D［7］提出了一種基于反演的柔性工作流和反射對(duì)象知識(shí)庫 ROK（Reflective Object Knowledge）來支持對(duì)工作流結(jié)構(gòu)各類特征的處理。這個(gè)框架支持工作流的運(yùn)行時(shí)反射，但不能覆蓋整個(gè)軟件生命周期。

2.3 RGPS支持的面向方面網(wǎng)絡(luò)式軟件演化方法及其問題

面向方面的軟件演化方法覆蓋整個(gè)軟件生命周期［8，9］，所以何克清等［10］采用了面向方面的網(wǎng)絡(luò)式軟件運(yùn)行時(shí)反射的框架，如圖1所示。該框架把運(yùn)行時(shí)的 Web服務(wù)組合具體化為以O(shè)WL-SA（Ontology Web Language-Service Aspect）呈現(xiàn)的描述，然后通過解析目標(biāo)變更需求規(guī)格來調(diào)用相應(yīng)的動(dòng)作對(duì)呈現(xiàn)的描述進(jìn)行修改，并將這種修改反饋給基層的Web服務(wù)組合實(shí)例，使之動(dòng)態(tài)演化，從而滿足用戶的個(gè)性化需求。

Figure 1 Runtime reflection framework of network software圖1 網(wǎng)絡(luò)式軟件運(yùn)行時(shí)反射的演化框架

文獻(xiàn)［10］提出的網(wǎng)絡(luò)式軟件演化框架中，需求規(guī)格是以流程資產(chǎn)的形式呈現(xiàn)，而流程資產(chǎn)滿足RGPS流程元模型的約束，RGPS元模型定義如圖2所示。

Figure 2 RGPS process meta-model圖2 RGPS中的流程元模型

該框架的演化過程是：首先，在RGPS元模型指導(dǎo)下形成演化的初始需求模型。其次，當(dāng)需求發(fā)生變化的時(shí)候，在以領(lǐng)域模型為元模型、目標(biāo)模型為基本模型的反射機(jī)理支撐下，動(dòng)態(tài)形成目標(biāo)需求模型，并以O(shè)WL-SA表示，如圖3a所示，其中以切入點(diǎn)（Pointcut）描述插入方向，通知（Advice）描述需求演化內(nèi)容。為便于比較，圖3給出了改進(jìn)后的元模型，其改進(jìn)內(nèi)容在3.1節(jié)中詳細(xì)介紹。

Figure 3 OWL-SA meta-model圖3 OWL-SA元模型

該框架實(shí)現(xiàn)了運(yùn)行時(shí)網(wǎng)絡(luò)式軟件的在線演化，但是仍然存在如下問題：

（1）在 OWL-SA元模型中，evolutionOrder屬性值有四個(gè)：before，after，around，parallelTo，分別表示通知與切入點(diǎn)所在的過程之間的關(guān)系為在前、在后、替換或并行。該定義并未嚴(yán)格遵守RGPS中流程元模型控制結(jié)構(gòu)的定義，導(dǎo)致織入的新流程與原流程的關(guān)聯(lián)關(guān)系定義不清楚，容易引起某些流程無法演化。例如，圖4中在節(jié)點(diǎn)p5前插入方面，因?yàn)闆]有定義控制結(jié)構(gòu)，因此p2、p3和p1、p6的關(guān)系無法確定，導(dǎo)致該方面無法織入。

Figure 4 Problems in evolution圖4 演化中出現(xiàn)的問題

類似地，圖4中與p5并行及圖4下半部分圖中p1之后插入通知都是無法用OWL-SA元模型準(zhǔn)確描述的。

（2）確定演化的位置方法可操作性差。正如（1）所述，因?yàn)榍腥朦c(diǎn)和原流程采用不同的控制結(jié)構(gòu)定義方法，導(dǎo)致切入點(diǎn)的織入不夠平滑，原框架采用XPath定位OWL-SA中的演化位置，技術(shù)上是可行的，但是普通用戶使用起來十分困難。

3 方法的改進(jìn)

3.1 改進(jìn)的流程形式化定義

由圖3可知，每個(gè)通知對(duì)應(yīng)一個(gè)流程。又根據(jù)圖2所示的流程元模型可知，每個(gè)流程又分成原子流程和組合流程。所以，當(dāng)通知需要執(zhí)行多個(gè)操作時(shí)可以用組合流程來替代，因此每個(gè)通知可以完全用流程來代替。流程元模型利用控制結(jié)構(gòu)來表示流程之間的邏輯順序，直接將該控制邏輯引入方面中作為切入點(diǎn)在流程中位置定義的描述是合適的。因此，本文對(duì)OWL-SA元模型進(jìn)行修改，將演化順序合并到流程中，將通知和流程一對(duì)一合并形成圖3所示的修改后元模型，并給出RGPS流程元模型指導(dǎo)下的流程模型，其形式化定義如圖5所示。

Figure 5 Formal definition of process圖5 流程形式化定義

圖5 中各個(gè)元素的含義如下：

（1）Title：流程場(chǎng)景名稱。

（2）ProcessTitle：流程中包含的流程的名稱，如｛（p1，“訂飛機(jī)票”）｝。

（3）AllElements：包含的所有元素，包括通知（Advice）、子流程（SubProcess）、分支開始（SplitOn）、分支匯聚（SplitJoin）、條件分支（Choice）。這些元素遵從RGPS元模型指導(dǎo)，并且與RGPS元模型中的元素建立對(duì)應(yīng)關(guān)系，如表1所示。

Table 1 Process model and the corresponding RGPS meta-model表1 新定義的流程模型與RGPS元模型的對(duì)應(yīng)

（4）Sequence：兩個(gè) Elements之間的順序關(guān)系。

（5）InitialElements和 Terminators：開始和結(jié)束的元素集合，可以是子流程（SubProcess）、分支開始（SplitOn）、分支匯聚（SplitJoin）、條件分支（Choice）和方面（Advice）。

（6）Superior：元素所屬的父流程或者父方面。

（7）Pre和Post：方面執(zhí)行的前置和后置條件。

（8）Localvariable：流程中使用到的參數(shù)。

（9）Inputs和Outputs：某個(gè)流程的輸入和輸出參數(shù)。

（10）ChoiceRules：選擇分支的條件。

（11）APCall：原子流程可以調(diào)用的 Web服務(wù)。

（12）Expectations、Actor、Goal：對(duì)應(yīng)元模型中流程對(duì)期望、角色和目標(biāo)的調(diào)用。

Figure 6 Process invariant圖6 流程不變式

元素之間的約束放在不變式中，如圖6所示，其含義為：

（1）流程中包含的元素有子流程（SubProcess）、分支開始（SplitOn）、分支匯聚（SplitJoin）、條件分支（Choice）和通知（Advice），它們是各不相同的。

（2）終止點(diǎn)必須滿足一定的條件。

（3）每個(gè)元素都有自己的名稱。

（4）順序反映了流程圖中的順序結(jié)構(gòu)，連接了兩個(gè)元素。

（5）每個(gè)原子流程都屬于一個(gè)流程。

（6）每個(gè)輸入或輸出必須屬于一個(gè)流程。

（7）每個(gè)分支條件必須屬于一個(gè)分支。

流程模型與RGPS流程元模型的對(duì)應(yīng)關(guān)系。

從表1中可以看到，每一種流程元素都可以在元模型中找到對(duì)應(yīng)的元素，這表示新建立的模型是遵循RGPS元模型指導(dǎo)的，完全可以用元模型來表示。在RGPS元模型中還有一種控制結(jié)構(gòu)是Loop結(jié)構(gòu)，雖然在流程模型中沒有一種元素和它對(duì)應(yīng)，但是它代表的控制完全可以用Choice和SubProcess的組合來替代。

3.2 流程演化

在網(wǎng)絡(luò)式軟件演化框架［10］中，首先在RGPS元模型指導(dǎo)下形成演化的初始需求模型。只有當(dāng)需求發(fā)生變化的時(shí)候，才會(huì)把變化的需求以O(shè)WLSA形式表示并將其織入到以流程資產(chǎn)形式表示的需求模型中，因此流程的演化只涉及到模式級(jí)別。這種演化主要包括三類情況：流程元素的插入、刪除和替換，而替換又可以看成是先刪除再插入，所以本文主要討論兩種情況：流程元素的插入和刪除，如圖7所示。

Figure 7 Process elements insertion and deletion圖7 流程元素插入與刪除

流程元素的插入主要包含插入順序結(jié)構(gòu)、插入分支開始、插入分支匯合、插入子流程、插入選擇分支。插入順序結(jié)構(gòu)的時(shí)候，如果是從一個(gè)選擇節(jié)點(diǎn)之后插入，那么還需要插入選擇分支的條件。流程元素的刪除主要包含刪除順序結(jié)構(gòu)、刪除分支開始、刪除分支匯合、刪除子流程、刪除選擇分支。刪除過程容易造成某些節(jié)點(diǎn)失效，因此需要進(jìn)行清理。

3.2.1 插入元素

（1）如圖8所示，插入子流程（InsertSubProcess）的操作將一個(gè)新的子流程節(jié)點(diǎn)插入到流程結(jié)構(gòu)中。子流程名稱和它所屬的父流程作為操作的輸入，該操作會(huì)產(chǎn)生一個(gè)輸出pro作為新子流程的流程編號(hào)。輸入的父流程（Parent）必須屬于Superior，產(chǎn)生的新id號(hào)pro不屬于已有的AllElements。該操作將pro加入到SubProcess，把子流程名稱processTitle加入到Process。其中，“’”操作表示某個(gè)屬性被執(zhí)行操作以后的新值，例如，AllElements’表示在執(zhí)行了InsertSubProcess操作之后AllElements的新值。

Figure 8 Process elements insertion圖8 插入元素

（2）插入順序結(jié)構(gòu)（InsertSequence）的操作將一個(gè)新的順序結(jié)構(gòu)插入到流程結(jié)構(gòu)中。順序結(jié)構(gòu)作為操作的輸入。該操作將新的順序結(jié)構(gòu)seq加入到Sequence。因?yàn)镾equence的定義為（From，To），當(dāng)執(zhí)行插入一個(gè)順序結(jié)構(gòu)的時(shí)候，將會(huì)把兩個(gè)節(jié)點(diǎn)連接起來。

（3）插入規(guī)則（InsertRule）操作將一個(gè)新的規(guī)則插入到流程結(jié)構(gòu)中。選擇節(jié)點(diǎn)和流程節(jié)點(diǎn)以及兩個(gè)節(jié)點(diǎn)連線上的條件構(gòu)成操作的輸入。該操作將新的規(guī)則加入到ChoiceRules。對(duì)于插入分支開始（SplitOn）、分支匯合（SplitJoin）和選擇節(jié)點(diǎn)（Choice）三個(gè)操作，其操作方式同插入子流程類似，文中不再贅述。

3.2.2刪除元素

（1）如圖 9 所示，刪除子流程 （DropSub-Porcess）操作將一個(gè)子流程從流程結(jié)構(gòu)中刪除。Sequence’的值將發(fā)生變化：所有到待刪除節(jié)點(diǎn)的順序結(jié)構(gòu)和所有從待刪除節(jié)點(diǎn)發(fā)出的順序結(jié)構(gòu)將連接起來，同時(shí)待刪除節(jié)點(diǎn)的定義域和值域要從順序結(jié)構(gòu)中刪除，即連接到待刪除節(jié)點(diǎn)或從待刪除節(jié)點(diǎn)發(fā)連線都將被刪除。然后從子流程中將待刪除節(jié)點(diǎn)刪除，從父流程中將與待刪除節(jié)點(diǎn)相關(guān)的節(jié)點(diǎn)刪除。

Figure 9 Process elements deletion圖9 刪除元素

（2）刪除順序（SropSequence）操作將一個(gè)順序結(jié)構(gòu)從流程結(jié)構(gòu)中刪除；從父流程中將與待刪除節(jié)點(diǎn)相關(guān)的節(jié)點(diǎn)刪除。因?yàn)閯h除順序結(jié)構(gòu)容易造成某些節(jié)點(diǎn)不再和其他節(jié)點(diǎn)關(guān)聯(lián)，因此需要在刪除結(jié)構(gòu)執(zhí)行之后進(jìn)行清理工作，這也是圖7中Clean節(jié)點(diǎn)要做的工作。

（3）刪除選擇（DropChoice）操作將一個(gè)選擇結(jié)構(gòu)從流程結(jié)構(gòu)中刪除；從父流程中將與待刪除節(jié)點(diǎn)相關(guān)的節(jié)點(diǎn)刪除。因?yàn)檫x擇結(jié)構(gòu)還和選擇結(jié)構(gòu)上的條件相關(guān)，所以在ChoiceRule中將與待刪除節(jié)點(diǎn)相關(guān)的所有條件規(guī)則刪除。

（4）刪除分支開始（DropSplitOn）操作將一個(gè)分支開始結(jié)構(gòu)從流程結(jié)構(gòu)中刪除；從父流程中將與待刪除節(jié)點(diǎn)相關(guān)的節(jié)點(diǎn)刪除。同時(shí)Sequence’中做同刪除子流程一樣的操作，即將打斷的順序結(jié)構(gòu)依次連接起來。刪除分支匯合（DropSplitJoin）的操作同刪除分支開始。

4 演化實(shí)例

為了檢驗(yàn)提出的網(wǎng)絡(luò)式軟件演化方法的可行性和有效性，本文基于Flex4開發(fā)了一個(gè)演示系統(tǒng)?？紤]一個(gè)旅行規(guī)劃的場(chǎng)景：Rick先生希望定制一個(gè)行程規(guī)劃預(yù)訂到北京的機(jī)票，幫他在北京預(yù)訂酒店并提供當(dāng)?shù)孛麆俚臑g覽介紹。根據(jù)文獻(xiàn)［10］，Rick將在領(lǐng)域模型中獲得滿足自己需求的需求模板，簡(jiǎn)化形式如圖10中上面流程所示。當(dāng)他到中國(guó)以后發(fā)現(xiàn)中國(guó)是一個(gè)鐵路交通非常發(fā)達(dá)的國(guó)家，乘坐火車可能比飛機(jī)性價(jià)比更高，因此上述旅行規(guī)劃中的初始需求需要進(jìn)行演化，增加部分需求，從而變成圖10下面的流程。

4.1 演化方面定義

圖11中代表需求演化的方面為Aspect1，它主要包含：一個(gè)choice節(jié)點(diǎn)（P8974）、一個(gè)訂火車票的advice節(jié)點(diǎn)（P8826）和一個(gè)splitJoin節(jié)點(diǎn)（P4899）。它們各自的定義符合RGPS流程元模型的標(biāo)準(zhǔn)，以3.1節(jié)中的定義形式給出。

4.2 切入點(diǎn)位置定義

Figure 10 Original requirements and evolutionary requirements of travel planning圖10 旅行規(guī)劃的原始需求和演化需求

Figure 11 Evolutionary process source code圖11 演化后的流程代碼

切入點(diǎn)的位置定義和織入原流程的方式通過Sequence能夠清楚地表示：choice節(jié)點(diǎn)（P8974）、advice節(jié)點(diǎn)（P8826）和splitJoin節(jié)點(diǎn)（P4899）屬于同一方面（superior＝“Aspect1”）。其中，choice節(jié)點(diǎn)在Start節(jié)點(diǎn)（P1397）之后，advice節(jié)點(diǎn)在choice節(jié)點(diǎn)（P8974）之后，splitJoin節(jié)點(diǎn)在訂機(jī)票（P6295）和訂火車票（P8826）之后。advice同訂機(jī)票節(jié)點(diǎn)（P6295）都連接自choice節(jié)點(diǎn)（P8974）。從上面的代碼中可以看出，演化后的需求方面切入點(diǎn)的位置不需要顯式地定義，它們的定義隱式地包含在了流程控制結(jié)構(gòu)中，這樣的方式保證了演化需求可以無縫織入原過程。

5 結(jié)束語

本文針對(duì)現(xiàn)有網(wǎng)絡(luò)式軟件演化框架中存在的問題，提出了新的面向方面網(wǎng)絡(luò)式軟件演化方法。新的演化方法使用RGPS流程元模型定義流程，用流程元模型中的控制結(jié)構(gòu)定義切入點(diǎn)位置，從而精確定義了切入點(diǎn)位置并提供圖形化操作界面，方便了切入點(diǎn)插入操作。新方法除了保持了網(wǎng)絡(luò)式軟件運(yùn)行時(shí)演化的特點(diǎn)之外，還能夠使切入點(diǎn)的定義符合RGPS元模型的要求，但是新方法仍然沒有解決演化中的不一致問題，這也將是下一步的主要工作。

［1］ Wang Jian，He Ke-qing，Li Bing，et al.Meta-models of domain modeling framework for networked software［C］∥Proc of the 6th International Conference on Grid and Cooperative Computing，IEEE Computer Society，2007：878-885.

［2］ Liu Wei.Research on services-oriented software requirements elicitation and analysis［D］.Wuhan：Wuhan University，2008.（in Chinese）

［3］ Cazzola W，Pini S，Ancona M.AOP for software Evolution：A design oriented approach［C］∥Proc of the 2005ACM Symposium on Applied Computing，2005：1346-1350.

［4］ Charfi A，Mezini M.AO4BPEL：An aspect-oriented extension to BPEL［J］.World Wide Web，2007，10（3）：309-344.

［5］ Cazzola W，Ghoneim A，Saake G.RAMSES：A reflective middleware for software evolution［C］∥Proc of the 35th Annual Meeting of the ACL and the 8th Conference of the EA CL，2004：56-63.

［6］ Cazzo W，Pini S，Ghoneim A，et al.Co-evolving application code and design models by exploiting metadata［C］∥Proc of SAC’07，2007：1275-1279.

［7］ Edmond D，Der Hofstede A H M.A reflective infrastructure for workflow adaptability［J］.Data＆Knowlage Engineering，2004，34（3）：271-304.

［8］ Kellens A，Mens K，Brichau J，et al.Managing the evolution of aspect-oriented software with model-based point-cuts［C］∥Proc of the 20th European Conference on Object-Oriented Programming（ECOOP’06），2006：501-525.

［9］ Demeyer R，Assche M V，Vanhoof W.Declarative workflows to efficiently manage flexible and advanced business processes［C］∥Proc of PPDP’10，2010：209-218.

［10］ He Ke-qing，Peng Rong，Liu Wei，et al.Network Software［M］.Beijing：Science Press，2008.（in Chinese）

附中文參考文獻(xiàn)：

［2］ 劉偉.面向服務(wù)的軟件需求獲取與分析研究［D］.武漢：武漢大學(xué)，2008.

［10］ 何克清，彭蓉，劉瑋，等.網(wǎng)絡(luò)式軟件［M］.北京：科學(xué)出版社，2008.