RGPS支持的面向方面網(wǎng)絡式軟件演化方法＊

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

（1.山東科技大學信息學院，山東 青島266590；2.武漢大學軟件工程國家重點實驗室，湖北 武漢430072；3.湖南科技大學計算機學院，湖南 湘潭411201）

1 引言

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

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

2 軟件演化研究

面向方面和基于反射結構的軟件演化方法是當前實現(xiàn)軟件演化的兩大主流方法。

2.1 面向方面的演化方法

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

2.2 基于反射體系結構的軟件演化方法

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

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

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

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

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

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

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

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

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

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

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

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

（2）確定演化的位置方法可操作性差。正如（1）所述，因為切入點和原流程采用不同的控制結構定義方法，導致切入點的織入不夠平滑，原框架采用XPath定位OWL-SA中的演化位置，技術上是可行的，但是普通用戶使用起來十分困難。

3 方法的改進

3.1 改進的流程形式化定義

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

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

圖5 中各個元素的含義如下：

（1）Title：流程場景名稱。

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

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

Table 1 Process model and the corresponding RGPS meta-model表1 新定義的流程模型與RGPS元模型的對應

（4）Sequence：兩個 Elements之間的順序關系。

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

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

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

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

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

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

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

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

Figure 6 Process invariant圖6 流程不變式

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

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

（2）終止點必須滿足一定的條件。

（3）每個元素都有自己的名稱。

（4）順序反映了流程圖中的順序結構，連接了兩個元素。

（5）每個原子流程都屬于一個流程。

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

（7）每個分支條件必須屬于一個分支。

流程模型與RGPS流程元模型的對應關系。

從表1中可以看到，每一種流程元素都可以在元模型中找到對應的元素，這表示新建立的模型是遵循RGPS元模型指導的，完全可以用元模型來表示。在RGPS元模型中還有一種控制結構是Loop結構，雖然在流程模型中沒有一種元素和它對應，但是它代表的控制完全可以用Choice和SubProcess的組合來替代。

3.2 流程演化

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

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

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

3.2.1 插入元素

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

Figure 8 Process elements insertion圖8 插入元素

（2）插入順序結構（InsertSequence）的操作將一個新的順序結構插入到流程結構中。順序結構作為操作的輸入。該操作將新的順序結構seq加入到Sequence。因為Sequence的定義為（From，To），當執(zhí)行插入一個順序結構的時候，將會把兩個節(jié)點連接起來。

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

3.2.2刪除元素

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

Figure 9 Process elements deletion圖9 刪除元素

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

（3）刪除選擇（DropChoice）操作將一個選擇結構從流程結構中刪除；從父流程中將與待刪除節(jié)點相關的節(jié)點刪除。因為選擇結構還和選擇結構上的條件相關，所以在ChoiceRule中將與待刪除節(jié)點相關的所有條件規(guī)則刪除。

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

4 演化實例

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

4.1 演化方面定義

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

4.2 切入點位置定義

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

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

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

5 結束語

本文針對現(xiàn)有網(wǎng)絡式軟件演化框架中存在的問題，提出了新的面向方面網(wǎng)絡式軟件演化方法。新的演化方法使用RGPS流程元模型定義流程，用流程元模型中的控制結構定義切入點位置，從而精確定義了切入點位置并提供圖形化操作界面，方便了切入點插入操作。新方法除了保持了網(wǎng)絡式軟件運行時演化的特點之外，還能夠使切入點的定義符合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）

附中文參考文獻：

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

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