擴展Tropos目標模型驅動的軟件自適應方法研究*

王 欣

(渤海船舶職業學院 葫蘆島 125001)

擴展Tropos目標模型驅動的軟件自適應方法研究*

王 欣

(渤海船舶職業學院 葫蘆島 125001)

傳統模型驅動自適應方法通常使用軟件設計階段的體系結構模型引導軟件運行時自適應行為,導致自適應策略模型復雜度較高。為此,論文將抽象級更高的需求階段目標模型用作軟件自適應過程中的策略模型,提出一種目標模型驅動的軟件自適應方法。與體系結構模型驅動方法相比,由于該方法可忽略不必要的細節,因而能夠降低策略模型復雜度,有利于自適應策略的維護、擴展和重用。

模型驅動自適應; 體系結構模型; 目標模型

1 引言

對于傳統的自適應技術,通常由軟件開發人員在軟件需求分析階段預計未來軟件運行環境變化,并分別在軟件設計和實現階段制定和實現自適應策略,因此當軟件環境變化超出預設策略時,可導致軟件因不能適應新環境而發生失效[1]。基于反射計算的自適應技術將軟件設計成由自適應控制層和業務邏輯層構成的兩層結構,自適應控制層以開發階段的軟件模型作為自適應控制過程中的策略模型,并在此基礎上對軟件環境及其運行狀態進行監測、分析和推理,從而得到軟件的自適應策略[2]。

基于反射計算的自適應技術根據其自適應控制層使用的策略模型類型可分為:需求模型驅動、體系結構模型驅動以及實現模型驅動的自適應等。文獻[3～4]提出了一種體系結構模型驅動的自適應技術,以設計階段的體系結構模型作為自適應過程中的策略模型,其自適應過程中監測、分析、規劃、執行等活動均在體系結構模型上進行。文獻[5]采用社會組織的思想來抽象自適應軟件,描述和分析軟件的自適應特征,設計了基于角色動態綁定的自適應運行機制,并借助于增強學習的手段來實現軟件的在線自適應決策以應對不可預見的變化。文獻[6]將基于構件的體系結構模型用于軟件自適應過程,并根據構件的非功能屬性生成適應當前環境的軟件最佳配置策略。文獻[7]對UML類圖進行上下文擴展,提出一種面向對象的需求建模方法,并將其用于軟件自適應過程。文獻[8]將i*目標模型用于軟件運行時自適應決策過程,通過與目標模型關聯的斷言條件監測軟件需求,并在目標模型基礎上計算能夠適應當前環境的軟件配置。

盡管目前軟件自適應技術利用反射計算將軟件開發階段的模型應用于軟件運行階段,使軟件維護人員可通過修改模型來應對超出預期的環境變化,但它們仍存在下列不足:

1) 由于體系結構模型為軟件設計階段的產品,它與需求模型相比抽象級較低,因此以體系結構表示的策略模型復雜度較高,不利于策略的維護、擴展和重用;

2) 需求模型驅動的自適應方法使用高抽象級需求模型表示自適應策略,降低了策略模型的復雜度。但由于目前該技術采用的需求模型通常未考慮軟件對其內部異常事件的適應性需求,因此該類技術不能用于實現軟件對其內部異常事件的自適應處理。

針對上述問題,本文提出一種由目標模型驅動的軟件運行時自適應技術,對Tropos目標模型進行上下文條件、異常條件以及其他必要擴展,并用于引導軟件運行時的自適應行為。定義了必需滿足目標、可行目標、需求變體以及可選任務集的推理規則,用于根據當前環境和異常事件生成軟件自適應行為配置集。

2 擴展的Tropos目標模型

Tropos目標模型[9]將i*目標模型和面向Agent的思想相結合,為開發者提供一種用于構建面向Agent軟件需求模型的方法。目前Tropos目標模型的擴展方法研究主要關注如何建模對環境變化自適應的軟件需求,而對于如何建模對內部異常事件自適應的軟件需求,研究還不夠充分。為此,本文對Tropos目標模型同時進行上下文條件、異常條件等擴展,使其具備同時建模軟件對環境變化和異常事件的自適應需求。

2.1 上下文條件擴展

上下文是對軟件真實環境的抽象表示,它通常被用在模型中描述軟件關注對象所處的環境[10]。為建模軟件運行環境,本文將上下文條件作為一種顯式建模元素,并對Tropos目標模型中目標分解關系進行上下文擴展,通過上下文條件變化表示軟件環境變化。軟件可根據當前環境狀態所滿足的上下文條件確定目標分解沿哪些分支進行,直至得到與當前環境一致的軟件目標以及相關可執行任務。經過上下文擴展的目標分解關系如圖1所示。目標分解邊上標記ci、cj用來表示上下文條件,可通過檢驗上述條件是否為真判斷當前是否出現特定環境事件。

圖1 目標分解的上下文條件擴展

2.2 異常條件擴展

軟件運行過程中可能會出現一些異常事件,如軟件功能模塊發生失效,對應到目標模型中表現為任務未能正確執行。若在軟件運行過程中出現異常事件,則要求軟件能對異常事件進行適應性處理,以保證向用戶提供持續正確的服務。為使軟件異常能夠得到及時處理,需為可能出現異常的任務所在手段-目的分析邊設置異常條件,用于監測任務的執行過程中是否出現異常狀況。圖2為目標模型中兩種不同類型的手段-目的分析異常條件擴展。分支上符號ei、ej表示異常條件,它們分別用來檢測任務ti、tj實施過程中是否出現異常事件,以便能及時對異常事件進行自適應處理。

圖2 手段-目的分析異常條件擴展

2.3 目標類型擴展

軟件運行的正確性可通過驗證軟件是否實現了用戶的目標來確認,而目標是否實現的判定依據與目標的類型有關。為能夠監測軟件運行過程中的目標狀態,將目標擴展為保持型目標、實現型目標、查詢型目標和執行型目標。

1) 保持型目標:當軟件到達此類目標指定的目的狀態時,需要其繼續維護該目的狀態,直至持有該目標的參與者接收到可導致該目的狀態終止的請求。

2) 實現型目標:當軟件到達此類目標指定的目的狀態時,不要求其必須維護該目的狀態。

3) 查詢型目標:此類目標與實現型目標相似,區別在于它表示與數據查詢有關的目標。

4) 執行型目標:此類目標不必指定其目的狀態,而是側重于執行某個動作。

3 目標模型驅動的軟件自適應策略生成

目標模型驅動的自適應重配置方法根據軟件當前環境及其目標、任務狀態,通過軟件目標模型的變化性分析生成軟件所有可能的配置集。軟件根據當前環境或異常事件選擇合適的軟件配置,從而實現軟件對環境變化或異常事件的自適應重配置。本文通過對目標模型變化性分析,由軟件目標分析生成滿足該目標所有可選任務集,從而得到可供軟件選擇的行為配置集。當同一上下文條件下存在多個可選配置時,計算各配置的優先級,根據優先級最高的配置調整軟件行為。

3.1 應采納目標、可采納目標與可選擇任務判斷規則

定義1 應采納目標:當前環境下軟件應當選取來滿足的目標,如果該目標未被選取,則軟件將發生失效。例如,當智能清潔機器人發現地面有灰塵時,其目標“清潔地面”為應采納目標,而當其電量不足時,其目標“補充電量”為應采納目標。

定義2 可采納目標:當前環境下軟件可以選取來滿足的目標,但當該目標未被選取時,軟件也不一定發生失效。例如,假設智能清潔機器人當前已采納目標“補充電量”,則它可選取目標“利用供電插座補充電量”來滿足該目標,或者選取目標“更換電池補充電量”來滿足該目標,因此目標“利用供電插座補充電量”和“更換電池補充電量”均為可采納目標。

定義3 可選擇任務:當前環境下軟件為滿足其目標可選擇執行的任務。例如,假設當前智能清潔機器人已采納目標“清潔地面”,由于它可選擇任務“掃地”或“擦地”滿足該目標,因此任務“掃地”和“擦地”均為可選任務。

本文使用下列規則來判斷特定上下文條件下軟件應采納目標、可采納目標以及可選擇任務。

規則1 若g為目標(goal(g)),當前g的滿足過程未完成(done(g)),已發生使g進入活動狀態的事件(happened(activation_event(g))),且目標模型中不存在g的父目標gp經目標分解生成g(?gp(decom(gp,g,dec)),則目標g為應采納目標(should_do(g))。該規則以斷言形式可描述為

規則2 若g為應采納目標,則g也為可采納目標(optional(g))。該規則以斷言形式可描述為

規則3 若g滿足過程未完成,目標模型中存在可采納目標gp經目標分解生成g,且與gp到g的目標分解邊關聯的上下文條件為真(hold(context(dec))),則目標g為可采納目標。該規則以斷言形式可描述為

規則4 若任務t前提條件為真(hold(pre_condition(t))),t當前未執行(done(t)),存在目標g經手段-目的分析生成t(?g(goal(g)∧means_end(g,t,dec)),g到t的手段-目的分析邊關聯的上下文條件為真(hold(context(dec))),且g為可采納目標(possible(g)),則t為可選擇任務(possible(t))。該規則以斷言形式可描述為

3.2 需求變化性分析

目標模型使用目標建模軟件需求,并通過目標分解關系將抽象目標細化具體目標。由于目標分解關系產生的需求變體與其分解類型有關,因此下面分別給出對兩種不同類型目標分解關系的變化性分析及變體生成規則。

由目標“與”分解生成的子目標與其父目標關系為:當子目標均滿足時,其父目標滿足。經上下文擴展后,目標“與”分解生成的子目標與其父目標關系同環境有關,兩者間關系變為:當前環境下上下文條件為真的子目標均滿足時,其父目標滿足。由于子目標是否需要滿足依賴于與之關聯的上下文條件,因此當環境變化時,用于滿足父目標的子目標隨之變化。由此可見,上下文擴展的目標“與”分解關系能夠描述軟件需求的變化性。

規則5 若目標g為可采納目標,且g的目標分解類型為“與”分解,則當前環境下滿足目標g的需求變體variationg為當前所有可采納目標。該規則以斷言形式可描述為

由目標“或”分解生成的子目標與其父目標關系為:選擇滿足任何一個子目標,均能使其父目標滿足。經上下文擴展后,子目標的選擇受環境影響,即只能從當前可行子目標集中選取。因此,上下文擴展的目標“或”分解關系可用來描述軟件需求變化性。

規則6 若目標g為可選采納目標,且g的目標分解類型為“或”分解,則當前環境下可用于滿足目標g的變體variationg為當前任一可采納子目標。該規則以斷言形式可描述為

3.3 滿足目標的任務集分析

任務是軟件為滿足其目標需執行的活動,因此任務集可作為軟件的行為配置。目標模型中能夠用來由目標生成任務的模型結構為手段-目的分析,它包含兩種類型:手段-目的“與”分析和手段-目的“或”分析。

由手段-目的“與”分析生成任務與其目標關系為:若要滿足目標,則需執行其生成的所有任務。進行上下文擴展后,任務能否執行與其環境有關,因此若要滿足目標,則需執行當前環境下其所有可選擇任務。

規則7 若目標g為可采納目標,且g的手段-目的分析類型為“與”分析,則當前環境下滿足目標g的任務集為當前所有可選擇任務構成的集合。該規則以斷言形式可描述為

由手段-目的“或”分析生成任務與其目標關系為:若要滿足目標,則只需選擇執行其生成的任一任務。進行上下文擴展后,任務能否執行與其環境有關,因此只能在當前可行目標中任選一種任務。

規則8 若目標g為可采納目標,且g的手段-目的分析類型為“或”分析,則當前環境下滿足目標g的任務集為當前任一可選擇任務構成的集合。該規則以斷言形式可描述為

綜上所述,通過迭代使用上述需求變體生成規則和任務集生成規則,可由軟件整體目標(根目標)生成當前環境下能夠滿足該目標的需求變體以及可能的任務集,從而得到軟件的行為配置。

3.4 任務集的優先級計算

由于可能存在滿足同一需求變體的多個可能的任務集,因此需要提供一種手段從中選取一個合適的任務集,作為軟件適應當前環境的行為配置。由于軟件實現其功能的同時可能對軟件性能產生影響,在軟件目標模型中被建模為目標或任務對軟目標的影響關系,因此可以將目標模型中任務對軟目標的影響值作為選取任務集的依據。為此,本文將任務集中所有任務對軟目標影響值的加權平均作為其優先級。任務集的優先級計算公式如下所示:

priority(alt)=

其中,alt為可選任務集,t為任務。s為軟目標,contribValue(t,s)為任務t對軟目標s的影響值,正值表示積極影響,負值表示消極影響。weight(s)為軟目標s的權值,它為由用戶指定的非負整數,權值越大表示用戶認為該軟目標越重要。ableContrib(t)為所有受任務t影響的軟目標集合,totalContrib(alt)為任務集alt中任務對軟目標影響數的總和。

3.5 軟件對環境變化的自適應重配置

當運行環境發生變化時,自適應軟件能夠根據當前環境滿足的上下文條件,使用目標模型驅動的軟件配置集生成方法得到適應當前環境的軟件配置,并將其用來替換原有軟件配置。本文通過上述定義規則,采用由頂到底的方式分析軟件目標模型,由軟件目標逐步得到當前上下文條件下可滿足該目標的任務集(見算法1)。

算法1 當前上下文條件下系統配置生成

輸入：指定目標，當前上下文條件；

輸出：可滿足指定目標的任務集；

ConfigGenerate(Goal g) {

1 GoalTask[] variant←g;

2 GoalTask[][] variants←variant;

3 if(and_goal_decom(g)){

4 for(each gi∈SubGoal(g)&&possible(gi)){

5 GoalTask[] temp_1←gi;}

6 for(each varianti∈variants){

7 if(g∈varianti)

8 varianti=(varianti{g})∪temp_1;}}}

9 if(or_goal_decom(g)){

10 for(each varianti∈variants){

11 if(g∈varianti){

12 for(each gi∈SubGoal(g) && possible(gi)){

13 variants← (varianti{g})∪{gi};}

14 variants=variants{varianti};}}}

15 if(and_means_end(g)){

16 for(each ti∈means(g)&&possible(ti)){

17 GoalTask[] temp_2←ti;}

18 for(each varianti∈variants){

19 if(g∈varianti)

20 varianti=(variantsi{g})∪temp_2;}}}

21 if(or_means_end(g)){

22 for(each varianti∈variants){

23 if(g∈varianti){

24 for(each ti∈means(g) && possible(gi)){

25 variants←(varianti{g})∪{ti};}

26 variants=variants{varianti};}}}

27 for(each varianti∈variants){

28 for(each gi∈varianti){

30 ConfigGenerate(gi);}}

31 return variants;}

若目標g被“與”分解,則由規則5可知,可采取以g所有可采納子目標整體替換g(行3～8)。若目標g被“或”分解,則由規則6可知,可采取以g的可采納子目標分別替換g(行9～14)。同理,可以根據目標g的手段-目的分析方式確定滿足目標g的任務集(行15～26)。當變體集中變體含有目標元素,對該目標按上述方式進行遞歸分析(27～30),否則返回所有任務集,作為軟件適應當前環境的行為配置。

3.6 軟件對異常事件的自適應重配置

自適應軟件通常采用等價替換方式處理其運行過程中的異常事件,基于等價替換的軟件異常處理主要包括下列兩種方式:

1) 局部優先替換

局部優先替換方式注重如何縮小軟件重配置前后其結構與行為的差異性,以盡可能保持軟件的穩定性。基于上述思想,局部優先替換方式根據失效任務所關聯的目標,通過執行該目標下其他等價任務使目標滿足,以縮小異常處理時軟件行為與結構的變化。

2) 高優先級優先替換

高優先級優先替換方式在軟件當前配置中存在失效任務時,將選擇一個與當前任務集功能等價且優先級最高的任務集,將其作為新的軟件配置。盡管該異常處理方式能夠更好地滿足涉眾偏好,但同時也可能導致軟件結構或行為發生較大變化。

本文采用上述兩種方式相結合的方法,采取由底到頂方式分析軟件目標模型:若失效任務存在等價任務,則采取局部優先替換方式;否則,采用高優先級優先替換方式,使用高優先級等價任務集整體替換軟件當前任務集(見算法2)。

對于失效任務t,獲取與之關聯的目標g(行1)。若目標g被手段-目的“或”分析,則采用局部優先替換方式,使用優先級最高的任務替換當前失效任務(行2～7)。若目標g被手段-目的“與”分析,且g非根目標,則向上遍歷g的父目標gp(行8～11)。遍歷過程中,若目標gp被目標“或”分解,則通過分析gp生成其任務集集合,并將包含失效任務t的任務集從生成的任務集集合中刪除(行12～16)。采用高優先級優先替換方式,使用優先級最高的任務集替換當前失效任務集(行17～20)。如果目標g被手段-目的“與”分解且為根目標,或g被手段-目的“與”分析且無被目標“或”分解的祖先節點,則表示無可用于異常處理的等價任務或任務集(行21～22)。

算法2 對任務t的異常處理

輸入：當前任務集currentTasks,失效任務t;

輸出：異常處理結果；

ExceptionHand(Task[] currentTasks,Task t){

1 Goal g=Ends(t);

2 if(or_means_end(g)){

3 Task[] altTasks←Means(g){t};

4 for(each ti∈altTasks){

5 int[] pri←PriorityCompute(ti);}

6 if(?tj∈altTask&&Priority(tj)==Max(pri))

7 Alternate(t,tj);}}

9 gp=Parent(g);

11 gp=Parent(gp):}

12 if(or_goal_decom(gp)){

13 variants-ConfigGenerate(gp);

14 for(each altTasks∈variants){

15 if(t∈altTasks)

16 variants=variantsaltTasks;}

17 for(each altTasksi∈variants){

18 int[]pri←PriorityCompute(altTasksi);}

19 if(?altTasksj∈variants&&Priority(altTasksj)=Max(pri))

20 Alternate(currentTasks,altTasksj);}

21 else printf(“there is no alternative tasks!”);}

22 else printf(“there is no alterative tasks!”;)}

4 結語

針對目前由需求模型驅動和體系結構模型驅動的自適應方法存在的不足,如未考慮軟件對異常事件的自適應處理,模型復雜度較高導致策略模型難以被維護、擴展和重用等,提出了一種由目標模型驅動的軟件運行時自適應方法。該方法使軟件能夠通過分析目標模型得到可應對環境變化和異常事件的自適應重配置策略,定義了必需滿足目標、可行目標、需求變體以及可選任務集的推理規則,并設計了基于上述規則的環境自適應算法以及異常自適應算法。

[1] Souza V E S, Lapouchnian A, Mylopoulos J. System Identification for Adaptive Software Systems: A Requirements Engineering Perspective[C]//Proceedings of the 2011 International Conference on Conceptual Modeling, Berlin, German,2011:346-361.

[2] Mei H, Huang G, Lan L, et al. A Software Architecture Centric Self-Adaptation Approach for Internetware[J]. Science in China,2008,51(6):722-742.

[3] Mei H, Huang G, Zhao H, et al. A Software Architecture Centric Engineering Approach for Internetware[J]. Science in China Series F: Information Sciences,2006,49(6):702-730.

[4] 毛新軍,董孟高,齊治昌,等.開放環境下自適應軟件系統的運行機制與構造技術[J].計算機學報,2015,38(9):1893-1906.

[5] Horikoshi H, Nakagawa H, Tahara Y, et al. Dynamic Reconfiguration in Self-Adaptive Systems Considering Non-Functional Properties[C]//Proceedings of the 27th Annual ACM Symposium on Applied Computing, New York, USA,2012:1144-1150.

[6] Kneer F, Kamsties E. Model-based Generation of a Requirements Monitor[C]//Proceedings of the 21st International Conference on Requirements Engineering: Foundation for Software Quality, Essen, Germany,2015:156-170.

[7] Mizouni R, Matar M A, Mahmoud Z A, et al. A Framework for Context-Aware Self-Adaptive Mobile Applications SPL[J]. Expert Systems with Applications,2014,41(16):7549-7564.

[8] Shaker P, Atlee J M, Wang Shige. A Feature-Oriented Requirements Modelling Language[C]//Proceedings of the 20th IEEE International Conference on Requirements Engineering, Chicago, USA,2012:151-160.

[9] Mylopoulos J, Castro J, Kolp M. A Framework for Requirements-Driven Software Development[C]//Proceedings of the 13th International Conference on Advanced Information Systems Engineering, Interlaken, Switzerland,2001:108-123.

[10] Dey A K. Understanding and Using Context[J]. Personal and Ubiquitous Computing,2001,5(1):4-7.

Extended Tropos Goal Model Driven Software Adaptive Techniques

WANG Xin

(Bohai Shipbuilding Vocational College, Huludao 125001)

Traditional model-driven adaptive techniques usually use design phase architecture model to direct software runtime adaption behavior, which leads to the high complexity of the adaptive policy model. Therefore, this paper uses the higher abstract level requirement phase goal model as a strategy model of the software adaption process, and proposes goal model-driven software adaptive method. Compared with the architecture model-driven method, the method can reduce the complexity of the strategy model, which is beneficial to the maintenance, extension and reuse of the adaptive strategy.

model-driven adaption, architecture model, goal model

TP311

2016年9月9日,

2016年10月29日

王欣,女,碩士,研究方向:嵌入式系統。

TP311

10.3969/j.issn.1672-9730.2017.03.021