面向軟件非功能需求的軟件過程建模方法

張　璇　李　彤　王　旭　代　飛　謝仲文　于　倩

1(云南大學軟件學院　昆明　650091)2(云南省軟件工程重點實驗室(云南大學)　昆明　650091)3　　　(云南大學經濟學院　昆明　650091)

?

面向軟件非功能需求的軟件過程建模方法

張璇1,2李彤1,2王旭3代飛1,2謝仲文1,2于倩1,2

1(云南大學軟件學院昆明650091)2(云南省軟件工程重點實驗室(云南大學)昆明650091)3(云南大學經濟學院昆明650091)

(zhxuan@ynu.edu.cn)

摘要軟件非功能需求決定了軟件的質量，而軟件質量需求的滿足很大程度上依賴于軟件開發或演化時所使用的過程.從軟件過程的角度出發，總結凝練滿足軟件非功能需求的過程策略，使用面向方面方法，提出面向軟件非功能需求的軟件過程建模方法，從軟件過程的方法和技術角度保證軟件的質量需求貫穿軟件生命周期全過程得以實現.首先，基于對軟件非功能需求的分析，總結滿足非功能需求的過程策略，構建過程策略知識庫，在此基礎上，使用面向方面方法將過程策略定義的活動封裝為方面，并通過方面合成機制織入基本軟件過程模型，既實現了基本模型與面向非功能需求活動間的分離，又實現了軟件生命周期全過程注入有助于軟件質量提升的活動，其中，重點解決了方面織入基本模型的沖突控制及檢測問題;另外，通過開發面向非功能需求的軟件過程建模輔助工具NPAT(non-functional requirements-oriented processes aided tool)，為過程建模及沖突控制提供了技術支持;最后，通過在案例中使用所提出的理論、方法和技術，說明所提出的理論和方法是可行的，開發的輔助工具是有效的，可以通過非功能需求定制的軟件生命周期過程達到提升軟件質量的目標.

關鍵詞軟件非功能需求;軟件過程;面向方面建模;Petri網;沖突

保證軟件質量一直是軟件界追求的目標，軟件質量與軟件非功能需求(non-functional requirements, NFRs)密切相關，非功能需求解決的好壞直接影響軟件的成敗，因此，非功能需求也常常被稱為質量需求.面對不同的非功能需求，工業界和學術界都針對性地提出了不同的軟件工程過程，包括：軟件可靠性工程過程[1-2]、信息系統安全工程過程[3]、系統防危性工程過程[4-5]、易用性工程過程[6]、Boehm和In[7]針對軟件質量需求提出的過程策略以及微軟公司[8-9]提出的安全軟件開發生命周期過程(security development lifecycle, SDL)等，這些工程過程的提出都表明開發高質量軟件、實現軟件演化質量的提升，其本質是在開發軟件以及演化軟件的過程中滿足軟件的質量需求.

為了增加對軟件過程的理解，我們通常使用特定的方法對軟件過程進行抽象、表示和分析，即對軟件過程進行建模，并通過可執行(enactable)的軟件過程模型指導實際軟件開發活動，以規范軟件開發行為并最終提高軟件質量[10].在軟件過程建模領域，李彤教授[11]提出了一種軟件演化過程建模方法，用于對軟件過程進行建模.但是，針對軟件質量，其特定的非功能需求如何融入軟件過程模型是我們面臨的新需求，面對新需求我們需要研究2個問題：1)如何成功地將不同軟件的不同非功能需求與軟件過程分離，分離有利于靈活地控制軟件的非功能需求，軟件的非功能需求會因不同軟件而不同，又隨技術的進步而變化[12]，有效分離可以實現基于特定非功能需求定制特定軟件過程，創建可重用過程模型，為將來的項目提供可重用的軟件過程;2)分離后的非功能需求如何在建模時融入軟件過程并且保證正確地融入，這是我們需要研究的第2個問題，我們需要提出可行且高效的融入方法，既保證非功能需求相對獨立，又保證融入操作的正確性.

為解決上述問題，本文面向軟件非功能需求，借鑒可靠性工程過程[1-2]、信息系統安全工程過程[3]、系統防危性工程過程[4-5]、易用性工程過程[6]、Boehm和In[7]針對軟件質量需求提出的過程策略以及微軟的SDL過程[8-9]等相關軟件非功能需求的工程過程，提出滿足軟件非功能需求的過程策略，并結合李彤教授[11]在軟件過程領域提出的軟件演化過程建模方法，運用面向方面方法，將過程策略中的活動按照活動的粒度和軟件演化過程建模框架[11]定義過程方面和任務方面，在對方面編織沖突進行分析和控制后將其編織入用軟件演化過程建模方法建模的基本軟件過程模型(為描述簡潔，下面統一稱其為基本模型)，實現面向軟件非功能需求的軟件過程形式化建模，同時，同步相關案例研究和分析以檢查理論研究成果的合理性、有效性和可行性，實現基于過程控制在開發和演化條件下保障軟件質量的方法論的理論和實踐提升.

1相關工作

隨著工業界和學術界對軟件過程研究的深入發展，大量的研究實踐表明從軟件生命周期的早期階段開始，貫穿項目始終，通過流程化和規范化的過程來強化軟件質量是保障軟件質量的有效方法.軟件開發與演化是以過程為中心的，軟件過程是保證軟件質量的關鍵因素，而軟件非功能需求的滿足就應該通過嚴格的過程來實現，一個管理好的軟件過程可以支持高質量軟件的生產，如果軟件過程能夠支持演化則可以保障軟件演化的質量.

1.1軟件質量與軟件過程

過去30年，為提高軟件質量，不同學者和工程人員提出了不同的面向過程的方法，總結歸納這些方法，我們將它們分為3類，即過程改進模型、指定階段軟件開發方法和過程質量保證方法，這些方法都被證明有效地讓軟件過程生產出來的軟件提升了質量.由于本文使用指定階段軟件開發方法，因此，本文僅對這個領域的相關工作進行介紹.

為提升軟件的質量，指定階段軟件開發方法是在軟件開發生命周期過程中在特定階段指定執行一些有助于提升軟件質量的活動.Boehm和In[7]針對軟件非功能需求給出了實現相應軟件質量需求(包括：保障性、互操作性、易用性、性能、演化性、可移植性、成本、時間和可重用性)的過程策略.微軟定義安全開發生命周期過程SDL[8-9]以解決軟件開發團隊在產品開發過程中常常遇到的安全問題，并在其Windows,IIS和SQL Server等產品線上實施，保證了所生產軟件的安全性，SDL取得的顯著成效得到了學術界和工業界的廣泛關注.CLASP(comprehensive, lightweight application security process)[13]基于形式化的最佳實踐構建活動驅動、基于角色的過程構件集，以支持軟件開發團隊在早期將安全融入軟件開發生命周期，其成果證明形式化方法結合軟件過程是保證軟件安全性的有效方法.Beznosov和Kruchten[14]對于如何將安全保障方法和技術集成到敏捷軟件開發過程進行了初步的研究.由歐盟資助的SecureChange項目組[15]對安全演化過程進行研究，保證軟件系統演化后仍能滿足安全性、隱私和可靠性的需求.Ericson在其文獻[16]中提出系統防危性(safety)是一個有條理的過程，這個過程是一個貫穿系統生命周期且具備前瞻性的過程，為了保證前瞻性，就必須在系統還處于概念階段時就定義生命周期各個階段控制及避免危險的任務，相對于向系統增加防危性特征的方法，這種軟件過程控制的方法成本更低、效率更高.美國國防部系統防危性標準實踐MIL-STD-882D[5]的核心系統防危過程包括8個階段，分別指定了系統生命周期中各個階段需要執行的防危性任務.這類方法在軟件生命周期全過程中增加特定的活動，保證生產出來的軟件能夠通過這些活動提升其質量.

另外，本文使用面向方面方法擴展軟件演化過程建模方法[11]，由于軟件演化過程建模方法基于的主要形式化方法是Petri網，因此本文對面向方面方法和面向方面Petri網領域的相關研究進行介紹.

1.2面向方面方法相關研究

基于Petri網的面向方面建模最早是Roubtsova和Aksit[17]于2005年提出，他們基于經典Petri網將方面Petri網定義為一個包含基本網、方面網和編織表達式的三元組，并定義連接點模型，用于描述在庫所和變遷上的靜態編織.之后，Xu和Nygard于2006年在其文獻[18]中提出基于面向方面編程(aspect-oriented programming, AOP)思想的面向方面謂詞變遷網，他們借用AspectJ的思想，定義封裝了切點、通知和聲明(introduction)的方面模型，其中：聲明網建模通知的功能，連接點是基本網的變遷、謂詞和弧，通知網定義連接點上的切點操作模式和相對位置(before，after或者around).2008年，Guan等人[19]延續Xu和Nygard的面向方面謂詞變遷網提出面向方面庫所變遷網，其定義中去除了AspectJ的聲明定義，方面網僅封裝了通知和切點，并且定義了編織網用于描述方面網編織入基本網后得到的面向方面庫所變遷網，在此基礎上，他們重點研究了方面間的沖突問題及解決方法.2010年，付志濤[20]借助于面向方面思想將軟件過程劃分為具有核心功能的過程和具有橫切屬性的過程(即方面)，同樣基于Xu和Nygard[18]的方法將方面編織到核心軟件過程以提高軟件過程演化的效率和質量.2012年，Molderez等人[21]通過定義編織器、連接點模型、切點語言、通知語言和合成機制，非形式化地將面向方面特征加入到Petri網中.

面向方面方法中方面的編織可能會干擾基本模型或者其他方面，Durr，Bergmans，Aksit在其文獻[22]中就指出：方面干擾問題是面向方面方法所剩余需解決的挑戰之一.目前大部分學者和工程人員主要研究并解決多方面在共享連接點(shared join points, SJPs)的沖突問題.在AspectJ中，通過聲明優先級方式來控制方面間的執行順序，使用關鍵詞dominate對存在沖突的方面進行重新排序，有限地解決了方面間順序控制問題[23].Kniesel和Bardey[24]基于方面間的觸發和抑制關系建立編織交互依賴圖，通過分析依賴關系確定方面編織順序，保證方面編織的完整性和正確性，從而解決方面間不期望產生的交互沖突.2009年，Kniesel[25]進一步完善其2006年與Bardey[24]共同完成的成果，并在原成果基礎上提出“編織計劃(weaving schedule)”來保證方面編織的完整性和正確性，并增加了方面編織之后的干擾診斷及修復方法.Dinkelaker等人[26]使用面向方面方法檢測、消解軟件系統特征間的異常交互，提出AO-FSM(aspect-oriented finite state machines)，用切點定義需觀察的狀態機執行模式，當切點模式匹配異常交互時，通知攔截引發異常的沖突并予以消解.這些方法在一定程度上控制了多個方面在共享連接點上的沖突問題并嘗試對方面編織沖突進行自動檢測.

2面向軟件非功能需求的軟件過程建模框架

本文使用指定階段軟件開發方法，在軟件生命周期過程中的特定階段指定執行一些有助于提升軟件質量的活動，為表示這些活動是面向軟件非功能需求，與軟件質量有關的活動，本文后續內容中使用NFR活動來表示這類特殊指定的活動.

基于NFR活動，傳統的方法是將這些活動與面向軟件功能需求的過程活動交織在一起實施建模，然而，這種將2類活動毫不區分的組織在一起的方法，不利于針對不同軟件的不同非功能需求定制軟件過程，而且，軟件需求“易變性”特征尤為突出，當需求發生變更時，2類活動“糾纏”(tangling)在一起，對其中任何活動的改變都有可能影響其他活動甚至破壞整個軟件過程，“糾纏”問題必然導致軟件過程難以維護、缺乏柔性且不利于重用.

本文基于面向方面方法的思想將實現軟件非功能需求的NFR活動封裝為NFR方面，將面向功能需求的軟件過程建模為基本模型，面對不同的非功能需求，不同的NFR活動被封裝為方面后編織入基本模型，當面對需求變更時，NFR方面與基本模型之間的相對獨立性有利于我們對軟件過程實施適應性調整，提升了軟件過程建模的柔性、可維護性和可重用性.

在軟件過程建模領域，基于Petri網擴展面向對象技術和霍爾邏輯，軟件演化過程建模方法[11]可以形式化地定義軟件過程中所有任務、活動和過程的結構及行為.軟件過程建模方法是本文用于建模基本模型的工具，在此基礎上，針對不同軟件的不同非功能需求，我們使用面向方面方法實施擴展，提出面向軟件非功能需求的軟件過程建模方法.下面首先介紹過程策略知識庫的構建.

2.1面向非功能需求的過程策略知識庫

通過總結相關學者及研究機構提出的軟件可靠性工程過程[1-2]、信息系統安全工程過程[3]、系統防危性工程過程[4-5]、易用性工程過程[6]、Boehm和In[7]針對軟件質量需求提出的過程策略以及微軟公司的安全軟件開發生命周期過程SDL[8-9]等，我們提出如表1所示的面向軟件非功能需求的NFR活動集合：

Table 1　Non-Functional Requirements-Oriented NFR Activities

Continued (Table 1)

面向軟件非功能需求的NFR活動并非一成不變，隨著時代的發展、技術的進步以及不同項目需要和不同專家建議，NFR活動應該根據軟件具體需要動態調整.

在將NFR活動封裝為NFR方面編織入基本模型時需要指定其編織位置和編織類型，因此，我們用過程策略庫存儲NFR活動及其在基本模型中的編織位置和編織類型，當有不同非功能需求提出來時，選擇過程策略即是選擇合適的NFR活動并可直接根據其編織位置模式和編織類型封裝NFR方面，有利于NFR活動在多個建模項目中反復使用.

過程策略庫的結構是用擴展的巴科斯范式(extended Backus-Naur form, EBNF)定義的.一個過程策略由一個NFR活動及其編織位置和編織類型組成.NFR活動的定義遵循軟件演化過程建模方法[11]的活動定義，即一個NFR活動是一個抽象數據類型，定義了數據結構及在數據結構上的操作.輸入、輸出和本地數據結構用于描述活動執行所使用的資源.如果一個NFR活動細化為一個NFR任務集合，則NFR活動體定義為NFR任務方面列表；如果一個NFR活動定義為一個NFR過程，則NFR活動體定義為NFR過程方面的標識.

2.2面向非功能需求的軟件過程建模框架

基于分層的思想，軟件演化過程建模方法定義了軟件過程建模框架[11]，即當一個高層的活動細化為一個軟件過程或者多個任務時，軟件過程模型的層次結構就開始形成.面向非功能需求的軟件過程建模保持原有框架結構實施面向方面擴展，擴展后的框架如圖1所示.

面向非功能需求的軟件過程建模框架的核心擴展源是NFR活動，按照軟件演化過程建模方法中活動的定義，NFR活動的形式化定義如下：

定義1. 一個NFR活動是一個四元組nA=(I,O,L,B)，其中：I，O，L是活動體B操作的輸入數據結構、輸出數據結構和本地數據結構，活動體B是一個軟件過程或者一個任務集合.一個NFR活動定義為一個類，稱為NFR活動類，當NFR活動執行時，創建NFR活動對象.

如果一個NFR活動細化為一個過程，這個過程就封裝為過程方面，如果一個NFR活動細化為一個任務集合，其中的每一個任務都封裝為任務方面，過程方面和任務方面統稱為NFR方面.

Fig. 1　Non-functional requirements-oriented software process modeling framework.圖1　面向非功能需求的軟件過程建模框架

定義2. 一個NFR方面是一個四元組nS=(id,d,k,type)：

1)id是NFR方面的標識；

2)d是通知(advice)，定義NFR方面擴展或者約束基本模型的行為；

3)k是切點(pointcut)，定義NFR方面織入基本模型的位置模式；

4)type是NFR方面的編織類型(before，after或者around).

使用軟件演化過程建模方法[11]在過程層建模的軟件過程在本文中稱為基本模型，基本模型可以被過程方面擴展或者約束.

定義3. 一個過程方面是一個四元組pS=(idp,dp,kp,type)，其中：idp是過程方面標識符，dp是過程通知，kp是過程切點集合，type是過程方面織入類型.

定義4. 一個過程通知是一個五元組dp=(C,A;F,Ae,Ax)：

1) (C,A;F)是一個沒有孤立元素的網，A∪C≠?；

2)C是條件的有限集，?c∈C稱為一個條件；

3)A是活動的有限集，?a∈A稱為一個活動，a的發生稱為a的執行或者點火；

4)F是弧的有限集，F?(C×A)∪(A×C)，對于c,a∈C,A，若(c,a)∈F或者(a,c)∈F，則在c和a之間有一條有向邊，稱為弧；

5)Ae,Ax?A分別是dp的入口活動集和出口活動集.若(C,A;F)包含一個環(c1，a1)，(a1，c2)，…，(cn，an)，(an，c1)導致Ae和Ax無法確定，或者Ae無法確定，或者Ax無法確定，則針對無法確定的Ae或者Ax，指定ae∈A為環的入口活動、ax∈A為環的出口活動，并在ae前增加一個活動a，滿足a?=?ae(a?是活動a的后集，?ae是活動ae的前集)，同時，在ax后增加一個活動b，滿足ax=?b，則Ae=Ae∪{a}和Ax=Ax∪{b}.

過程通知是一個沒有格局的基本Petri網(本文后續內容所有相關Petri網的符號定義使用吳哲輝在其文獻[27]中的定義)，沒有格局意味著過程通知中的活動沒有發生權，只有將過程方面編織入基本模型的過程(下面簡稱為基本過程)后，其中的活動在編織后的過程模型格局中才有發生權.過程通知的建模基于軟件演化過程建模方法中基本塊和過程包定義[11]，應用白盒建模及黑盒建模方法實現.當應用白盒方法建模時，過程通知中的一個活動細化為一個基本塊；而應用黑盒方法建模時，活動細化為一個過程包，隱藏其內部結構.

另外，過程方面的織入有明確的切點，因此，基于基本過程，過程切點采用枚舉方式定義：

定義5. 過程切點是由基本過程p=(C,A;F,M0)中的元素構成的集合kp={x|x∈p.C∨x∈p.A∨x∈p.F}，按照基本過程p的條件C、活動A和弧F三種元素，過程切點定義為

1) 條件切點集合{p.c|c∈C}；

2) 活動切點集合{p.a|a∈A}；

3) 弧切點集合{p.f|f∈F}.

使用軟件演化過程建模方法[11]在任務層建模的任務在本文中稱為基本任務，同樣，基本任務也可以被任務方面擴展或者約束.

定義6. 一個任務方面是一個四元組tS=(idt,dt,kt,type)，其中：idt是任務方面標識，dt是任務通知，kt是任務切點，type描述通知dt的織入類型.

定義7. 一個任務通知是一個2-斷言dt=({Q1},{Q2})，定義了任務方面的功能，其中：

1)Q1和Q2是一階謂詞公式，{Q1}稱為前置條件，定義了任務通知dt執行前的狀態，{Q2}稱為后置條件，定義了任務通知dt執行后的狀態；

2)A(F)=({Q1},{Q2})是定義任務方面功能的2-斷言.

任務通知是一個不帶消息的2-斷言，即未編織的任務通知僅定義功能，沒有發生權，只有將任務方面編織到基本任務中，當任務方面接收到消息開始執行時，任務通知才能隨之執行.當然，任務通知的功能也可以基于軟件演化過程建模方法[11]分解為順序、選擇或者循環結構.

定義8. 任務切點kt是由基本任務t定義功能的2-斷言構成的集合kt={A(F)|A(F)=({Q1},{Q2})}，按照前斷言和后斷言定義的任務功能，任務切點定義為2-斷言切點：{t.({Q1},{Q2})}.

過程方面在過程層織入基本模型，任務方面在任務層織入基本模型，由于基本模型的一個切點上有可能有多個同類型方面需織入，不管是過程方面還是任務方面，此時，需將這多個同類型的方面編織為一個方面，然后再織入基本模型.為了區分這2種編織機制，本文定義合成機制.合成分為融合和編織，融合是方面間的對稱合成，2個方面融合后得到一個方面；編織是將方面織入基本模型，從而產生一個新模型.

合成機制通過明確定義合成操作將合成前獨立設計的方面融合為一個方面之后織入基本模型，形成合成后模型.合成操作由初始化、方面融合、沖突檢測與消解、方面織入4個步驟構成：

Step1. 初始化.初始化工作是建立一張編織計劃表WeavePlan，存儲方面織入切點及類型，如圖2所示：

Fig. 2　WeavePlan.圖2　編織計劃表

其中：nSj(j=1,2,…,m)是第j個NFR方面，ki(i=1,2,…,n)是方面的切點定義，方面織入類型用數值0，1，2…表示.

在將NFR方面編織入基本模型前需要檢查編織計劃表，當不同方面在同一切點以同類型織入(如圖2橢圓虛線框所示)時，需要先實施方面間融合操作(見Step2)；而當不同方面在同一切點以不同類型織入(如圖2橢圓實線框所示)時，需要按照織入操作的不同優先級順序織入(見Step4).

Step2. 方面融合.同切點同類型NFR方面織入基本模型之前必須先融合然后才能織入，因為在面向方面方法中，同一切點織入的多個方面間會出現相互排斥、執行順序不確定或者一個方面的執行受另一個方面約束等方面間沖突問題，而這類沖突問題是方面間依賴關系引起的，因此，對于同切點同類型NFR方面，需要根據方面間依賴關系首先實施融合操作.

Step3. 沖突檢測與消解.融合后的NFR方面在織入基本模型時仍有可能引發與基本模型間的沖突，導致編織后模型執行錯誤或者改變了原基模型的行為，因此，在實施方面織入操作之前，需要對潛在沖突進行檢測，若發現潛在沖突，給出沖突位置及原因，由建模者根據這些沖突信息修改NFR方面后再次檢測，直至所有方面織入無沖突，保證方面織入的正確性.

Step4. 方面織入.完成方面融合及織入沖突檢測后，一個切點上要么只有一個方面需要織入，要么有多個不同類型的方面需要織入，且沒有潛在沖突.此時，對于只有一個方面織入的情況，簡單實施方面織入操作；對于有多個不同類型方面的織入情況，按照織入類型的不同優先級關系實施織入操作.

基于上述合成操作，在任務層，任何一個基本任務若編織了任務方面，則得到NFR任務.

定義9. 一個NFR任務nT=({Q1},{Q2},Mr,Mu)是一個由基本任務t編織任務方面集合TS={tS1,tS2,…,tSm},(m>0)后產生的新任務，其中：

1)A(F)=({Q1},{Q2})定義了NFR任務nT的功能，其中nT.A(F)=t.A(F)+TS.A(F)；

2) 輸入消息nT.Mr=t.Mr，輸出消息nT.Mu=t.Mu，即NFR任務nT的消息集合是基本任務t的消息集合.

在過程層，任何一個基本過程如果編織了過程方面則得到NFR過程.

定義10. 一個NFR過程nP=(C,A;F,M0)是一個由基本過程p編織過程方面集合PS={pS1,pS2,…,pSm},(m>0)后產生的新軟件過程，其中：

1)nP.C=p.C∪PS.dp.C；

2)nP.A=p.A∪PS.dp.A；

3)nP.F=p.F∪PS.dp.F；

4)nP.M0=p.dp.M0.

合成了所有NFR方面后，全局層由基本過程和NFR過程構成.NFR過程是由基本過程編織了過程方面而得到的，一個NFR過程可以由子軟件過程和子NFR過程構成.沒有擴展過程方面的基本過程仍由其原來的子軟件過程構成.

定義11. 一個全局模型是一個三元組g=(P,NP,E)，其中：

1)P是基本過程集合，NP是NFR過程集合；

2)E?(P×P)∪(NP×NP)∪(NP×P)是二元偏序關系，稱為嵌入關系，E={(x,x′)|x.x′∈NP∪P∧x′嵌入到x中}，x′ 稱為x的子過程.

至此，面向軟件非功能需求的軟件過程建模框架已構建完成，在提出具體建模方法之前需要先提出消解方面合成沖突的方法.

3消解方面合成沖突

NFR方面的引入有可能在違背原有意圖的情況下導致多個方面之間產生沖突或者方面和基本模型之間產生沖突，沖突一旦產生則會導致方面編織后的模型產生錯誤、無法執行或者行為不符合預期等問題.因此，需要對方面有可能引入的沖突問題進行研究、分析、控制、檢測及消解.

針對2.2節提出的面向軟件非功能需求的軟件過程建模框架，下面研究過程方面和任務方面織入基本模型時，方面間、方面與基本模型間的沖突.

3.1方面間沖突

當一個切點上編織入多個NFR方面時，方面間可能產生排斥，執行順序不確定，或者一個方面的執行受另一個方面約束等問題，Kniesel和Bardey[24]認為這些方面間沖突問題源于不完整或者不正確的編織，所謂不完整的編織是指將所有方面編織入切點后，仍然有方面沒有實施其應有的影響；而不正確的編織是指方面編織后，有些方面實施了錯誤的影響.

這些沖突問題本質上源于方面間的依賴關系，當一個連接點上有數據依賴關系[11](數據依賴關系本質上反映了多個方面執行的順序問題)的多個方面需要織入時，要保證所有織入的方面具有發生權則需要這些方面按照數據依賴關系順序融合，否則織入的方面有可能織入了卻無法執行而丟失影響，因此，基于軟件演化過程建模方法中定義的數據依賴關系[11]，我們定義編織完整性如下：

定義12. 設NS={nS1,nS2,…,nSm}是一個共享切點的NFR方面集合，對于其中任意2個方面nSi和nSj中的通知di和dj(1≤i≤m，1≤j≤m且i≠j)，如果：

1) 通知為過程通知，通知中的活動ai和aj之間有數據依賴關系aiδdaj，有M[ai>(活動ai在標識M有發生權記為M[ai>，其中，標識M是Petri網的運行狀態[27])但M[aj>，M[ai>M′→M′[aj>(活動ai在標識M發生得到一個新的標識M′記為M[ai>M′[27])；

2) 通知為任務通知，任務通知di和dj之間有數據依賴關系diδddj，有任務通知功能的順序執行A(Fi):A(Fj)(“:”表示順序關系).

則稱方面編織是完整的.

同樣，針對共享切點上多個存在控制依賴關系[11](控制依賴關系本質上反映了某方面執行權受其他方面控制的問題)的多個NFR方面，必須按照控制關系實施選擇融合才能保證方面織入后不會不受控制而造成錯誤的影響，同樣基于軟件演化過程建模方法中的控制依賴關系[11]，我們定義編織正確性如下：

定義13. 設NS={nS1,nS2,…,nSm}是一個共享切點的NFR方面集合，對于其中任意3個NFR方面nSi，nSj，nSl中通知di，dj，dl(1≤i≤m，1≤j≤m，1≤l≤m且i≠j≠l)，如果：

1) 通知為過程通知，其中的活動ai，aj，al之間有控制依賴關系aiδcaj，aiδcal，有M[ai>M′，M′[aj>或者M′[al>但M′[{aj,al}>；

2) 通知為任務通知，任務通知di，dj，dl之間有控制依賴關系diδcdj，diδcdl，有任務通知功能的選擇執行A(Fj)|A(Fl)且PO(Xi,Yi)?PR(Xj)∨PR(Xl)(“|”表示選擇關系，一階謂詞公式PO(X,Y)和PR(X)定義參見文獻[11]).

則稱方面編織是正確的.

本質上，編織完整性是要求有順序關系的方面必須按照順序關系融合，編織正確性是要求有選擇關系的方面按照選擇關系融合，它們的滿足保證方面間無沖突.

3.2方面與基本模型間沖突

在任務層，當任務方面織入基本模型的基本任務時，由于我們僅擴展基本任務的功能，不改變基本任務的消息機制，不會引入沖突.因此，下面我們僅對過程方面與基本模型的基本過程間的沖突進行研究.

在過程層，研究過程方面與基本過程之間的沖突問題，1)需要建立軟件過程模型正確性的概念,我們對軟件過程進行建模的主要目的之一是借助模型來分析實際過程的性質和功能，當軟件過程模型確切地描述了一個軟件過程的結構和運行狀態時，這個過程所具有的性質和行為就會在其過程模型上得到體現，其中：一些性質只與過程模型的結構有關，我們稱之為結構性質，另外一些性質與過程模型的運行有關，我們稱之為動態性質，而過程模型是否符合過程需求則是對過程模型行為的要求.當過程模型滿足結構性質和動態性質，并且行為與過程需求一致時，我們說過程模型滿足正確性.那么，當我們針對不同軟件提出不同非功能需求，而將過程方面織入軟件過程模型時，方面織入的沖突則體現為：軟件過程模型在沒有過程方面織入之前滿足結構性質和動態性質且行為一致，而在過程方面織入之后不滿足結構性質或動態性質或產生行為不一致問題.因此，過程方面與基本過程之間可能產生的沖突我們按照結構、性質和行為分為3類展開研究.

2) 由于過程方面僅在切點定義位置織入基本過程，其引入的沖突只可能作用于切點周圍的活動，因此，在過程層對沖突的分析不需要覆蓋編織后的整個過程模型，而僅限于織入切點周圍可能存在潛在沖突的過程片段，下面對潛在沖突過程片段進行定義：

定義14. 設pS=(idp,dp,kp,type)是一個過程方面，p=(C,A;F,M0)是一個基本過程，pS織入p，

潛在沖突過程片段以切點周圍的活動和織入過程方面的過程通知入口及出口活動為中心，將這些活動以及與這些活動相關的條件和弧定義為潛在沖突過程片段.

根據上述對沖突類型的分析，結構沖突僅與過程模型的拓撲結構有關，與過程模型的初始格局無關，而格局反映了過程的運行狀態，與運行狀態有關的沖突我們稱為性質沖突.為建立方面織入無沖突的基線，根據上述對潛在沖突過程片段的定義，我們提出如下無結構沖突和無性質沖突的定義：

1) 如果?a∈dp.A且?M∈R(p.M0)(R(p.M0)是從p.M0可達的一切標識的集合)，M[a>；

行為沖突在過程方面織入基本過程中特指編織后基本過程的活動關系與過程需求不一致.軟件演化過程建模方法用基本塊細化活動[11]，而基本塊中活動間關系包括順序、選擇、并發和迭代，因此，用這種方法建模的軟件過程模型的行為由這4種關系構成，當過程方面織入后，不能破壞它們原有的行為關系.

為建立過程方面織入無行為沖突的基線，下面首先對基本過程中活動的4類行為關系進行定義：

定義17. 設p=(C,A;F,M0)為一個軟件過程，ai,aj∈A，M∈R(M0)(R(M0)是從M0可達的一切標識的集合)，如果：

1)M[ai>但M[aj>；

2) ?σ∈A*使得M[ai>M′[σ>M″→M″[aj>.

則稱ai和aj之間是順序行為關系.當活動序列σ長度為0時，M[ai>M′→M′[aj>，稱ai和aj是直接順序行為關系；當活動序列σ長度不為0時，稱ai和aj是間接順序行為關系.

定義18. 設p=(C,A;F,M0)為一個軟件過程，ai,aj∈A，M∈R(M0)，如果：

1) 對于?σ∈A*，有M[ai>且M[σ>或者M[aj>且M[σ>；

2)M[σ>M1[ai>M2→M1[aj>∧M2[aj>但M[aj>M′→M′[σ∧M′[ai或者M[σ>M3[aj>M4→M3[ai>∧M4[ai>但M[ai>M″→M″[σ∧M″[aj.

則稱ai和aj之間是選擇行為關系.當活動序列σ長度為0時，有M[ai>且M[aj>，M[ai>M″ →M″[aj>或M[aj>M′→M′[ai>，稱ai和aj是直接選擇行為關系；當活動序列σ長度不為0時，稱ai和aj是間接選擇行為關系.

定義19. 設p=(C,A;F,M0)為一個軟件過程，ai,aj∈A，M∈R(M0)，如果：

1) 對于?σ∈A*，有M[ai>且M[σ>或者M[aj>且M[σ>；

2)M[σ>M1→M1[ai>∧M1[aj>且M1[ai>M′ →M′[aj>或者M1[aj>M″→M″[ai>，或者M[ai>M2[σ>M3→M3[aj>，或者M[aj>M4[σ>M5→M5[ai>.

則稱ai和aj之間是并發行為關系.當活動序列σ長度為0時，有M[ai>且M[aj>，M[ai>M2→M2[aj>或者M[aj>M4→M4[ai>，稱ai和aj是直接并發行為關系；當活動序列σ長度不為0時，稱ai和aj是間接并發行為關系.

定義20. 設p=(C,A;F,M0)為一個軟件過程，ai,aj∈A，M∈R(M0)，如果：

1)M[ai>但M[aj>；

2) ?σ∈A*使得M[ai>M′[σ>M″→M″[aj>M?[ai>.

則稱ai和aj之間是迭代行為關系.當活動序列σ長度為0時，M[ai>M′→M′[aj>M?[ai>，稱ai和aj是直接迭代行為關系；當活動序列σ長度不為0時，稱ai和aj是間接迭代行為關系.

基于上述活動間行為關系的定義，當過程方面織入基本過程時，無行為沖突定義如下：

定義21. 一個過程方面織入軟件過程模型無行為沖突當且僅當織入過程方面后潛在沖突過程片段中原基本過程的活動行為與織入前行為一致.

基于上述有關方面合成沖突的分析，我們首先提出控制過程方面與基本過程間沖突的方法.

過程方面的織入根據織入位置及織入類型分為10類織入操作，分別是條件前織入、條件后織入、條件周圍織入、活動迭代織入、活動前織入、活動后織入、活動周圍織入、活動并發織入、條件活動弧織入和活動條件弧織入.根據織入操作無沖突定義15、定義16、定義21，我們對這10類織入操作進行結構、性質、行為沖突的分析，通過分析，我們不允許使用下述4種存在沖突的操作，而使用其他無沖突的操作取代，其中，假設基本過程為p=(C,A;F,M0)，過程方面為pS=(idp,dp,kp,type).

1) 條件前織入操作是將過程方面在基本過程的條件切點前織入，如圖3所示，kp={p.c}，?c∈C.此織入操作結果是在以c為前集的所有活動前順序加入過程方面的過程通知，但此織入操作在切點條件c處產生潛在沖撞，根據無性質沖突定義16，不允許實施條件前織入操作，取而代之，用同等效果的條件活動弧織入操作實現過程方面的織入.

Fig. 3　Before condition weaving.圖3　條件前織入操作

2) 條件后織入操作是將過程方面在基本過程的條件切點后織入，如圖4所示，kp={p.c}，?c∈C.織入操作結果是在以c為后集的所有活動后順序加入過程方面的過程通知，但此織入操作會破壞基本過程的持續性，根據無性質沖突定義16，不允許實施條件后織入操作，取而代之，用同等效果的活動條件弧織入操作實現過程方面的織入.

Fig. 4　After condition weaving.圖4　條件后織入操作

Fig. 5　Before activity weaving.圖5　活動前織入操作

3) 活動前織入操作將過程方面的過程通知順序織入切點活動之前，如圖5所示，kp={p.a}，?a∈A.此織入操作本質上是為活動a的執行增加限制，要求必須在過程方面的過程通知執行之后才可以執行活動a，但是，當軟件過程中存在迭代結構而需要多次執行活動a時，此織入操作會導致活動a無法執行，因此，取而代之，用同等效果的條件活動弧織入操作實現過程方面的織入.

4) 活動后織入操作與活動前織入操作存在類似的沖突問題，kp={p.a}，?a∈A，如圖6所示，其本質是在切點活動a之后順序執行過程方面的過程通知，取而代之，用同等效果的活動條件弧織入操作實現過程方面的織入.

Fig. 6　After activity weaving.圖6　活動后織入操作

去除上述4類存在沖突的織入操作，并用無沖突的其他織入操作取而代之，在過程方面織入之前就避免與基本過程間產生沖突.

上述沖突控制方法屬于預防性方法，但是，建模過程仍然可能存在因疏忽等原因而引入沖突的可能性，而且，我們需要完全保證NFR方面織入基本模型的正確性，因此，下面我們根據無結構沖突定義15、無性質沖突定義16和無行為沖突定義21提出過程方面織入沖突檢測及消解方法，通過織入前控制沖突、織入過程中檢測并消解沖突，實現NFR方面織入完全無沖突保證.

3.3面向方面沖突檢測

本文繼續使用面向方面方法中的方面檢測沖突，用于檢測沖突的方面定義為沖突檢測方面，沖突檢測方面的切點定義為沖突模式，沖突檢測方面根據此沖突模式進行沖突檢測，當切點匹配存在沖突的連接點時檢測到沖突，此時，沖突通知阻止織入過程方面并記錄沖突類型、位置和導致沖突產生的過程方面，為建模者消解沖突提供相關信息.沖突檢測方面定義如下：

定義22. 一個沖突檢測方面是一個三元組FS=(id,k,d)：

1)id是沖突檢測方面標識，用于標識不同類型的沖突檢測方面；

2)k是切點(pointcut)，定義沖突模式；

3)d是通知(advice)，阻止過程方面織入并記錄沖突信息.

下面我們基于過程方面織入基本過程可能產生的結構和性質沖突，定義沖突檢測方面.

針對過程方面在過程層有可能引入的結構沖突，我們定義如圖7所示的結構沖突檢測方面：

Fig. 7　Detection aspects for structure conflict.圖7　結構沖突檢測方面

針對過程方面在過程層有可能引入的性質沖突，我們定義如圖8所示的性質沖突檢測方面：

Fig. 8　Detection aspects for property conflict.圖8　性質沖突檢測方面

由于可發生性沖突和持續性沖突都屬于活動無發生權的情況，因此，統一定義可發生性沖突檢測方面，如圖8(a)所示，當無發生權的活動在過程方面pS的過程通知dp中時，屬于可發生性沖突，當無發生權的活動在基本過程p中時，屬于持續性沖突.可發生性沖突檢測方面遍歷可達標識集合，如果存在活動a的前集條件不在可達標識集合中，說明活動a無發生權.對于圖8(b)所示的沖撞沖突檢測方面，如果存在M∈R(M0) (R(M0)是從M0可達的一切標識的集合)，有?a?M且a??M，那么活動a的后集條件存在沖撞.對于安全性沖突，由于B(c)>1的情況與沖撞沖突一樣，因此，僅檢測沖撞沖突.

4面向軟件非功能需求的軟件過程建模方法

面向軟件非功能需求，從過程策略知識庫選取過程策略，解決方面合成沖突并基于過程建模框架的過程建模流程如圖9所示，首先從活動層建模開始，然后根據活動分解的不同粒度，進行任務層建模和過程層建模;最后，完成全局層建模.

Fig. 9　Non-functional requirements-oriented software process modeling.圖9　面向非功能需求的軟件過程建模

Step1. 過程策略獲取.根據軟件的非功能需求，從過程策略知識庫中選取滿足這些非功能需求的過程策略.

Step2. 活動層建模.基于Step1得到的過程策略實施NFR活動建模，即在活動層設計NFR活動，定義NFR活動的輸入、輸出、本地數據結構及活動體，按照分解粒度不同，將活動體定義為一個軟件過程或者一個任務集合，并在此基礎上定義過程方面和任務方面.

Step3. 沖突控制及檢測.在NFR方面織入基本模型前解決可能產生的2類沖突:1)方面間沖突;2)方面織入的結構、性質或行為沖突.對于方面間沖突，此類沖突發生在同切點同類型織入的NFR方面之間，為了解決這類沖突，分析NFR方面之間的依賴關系，對于存在依賴關系的方面，按照依賴關系實施融合操作，具體融合操作見任務方面融合算法1.對于NFR方面與基本模型間的沖突，由于任務方面織入不會引入沖突，我們僅研究過程方面織入的結構、性質和行為沖突問題，為了解決這類沖突，使用預防性的沖突控制手段和織入時的沖突檢測方法，保證方面織入操作的正確性.具體沖突控制及檢測操作見過程層建模算法4.

Step4. 任務層建模.任務層建模是將任務方面織入任務層的基本任務.對于同切點同類型織入的任務方面，實施方面融合操作，對于不同切點或者同切點但不同類型的任務方面，實施方面織入操作.由于任務方面織入無沖突，下面僅給出任務方面融合操作算法1和任務方面織入操作算法2，其中，無依賴關系的任務方面根據實際情況實施順序融合或者選擇融合，在算法1中省略.

算法1. 任務方面融合NTask_Merging.

輸入:tS1=(idt1,dt1,kt1,type1),tS2=(idt2,dt2,kt2,type2),…,tSm=(idtm,dtm,ktm,typem);

輸出:tS=(idt,dt,kt,type),tS1=(idt1,dt1,kt1,type1),tS2=(idt2,dt2,kt2,type2),…,tSm=(idtm,dtm,ktm,typem).

分析tS1,tS2,…,tSm中所有任務的數據依賴關系RD和控制依賴關系RC;

IFl個方面存在依賴關系

分析tS1,tS2,…,tSl中所有任務的輸入輸出input(tSi),output(tSi),其中：

tSi∈tS1.dt1∪tS2.dt2∪…∪tSl.dtl;

END IF

調用Constructing_TDG(tS1.dt1∪tS2.dt2∪…∪tSl.dtl,input(tSi),output(tSi),RD,RC,TDG);*Constructing_TDG()是文獻[11]中構造依賴圖的算法，TDG是表示任務依賴關系的依賴圖*

轉換TDG為任務通知dt;

idt0;*0表示融合的任務方面標識*

kttS1.kS1∩tS2.kS2∩…∩tSl.kSl;

type=typel;

tS=(idt,dt,kt,type);

FORl=1 TOm

tSl.ktltSl.ktl-kt;

END FOR

算法2. 任務方面織入NTask_Weaving.

輸入:t,tS；

輸出:nT= ({Qx},{Qy},Mr,Mu).

nT.{Q1}?;nT.{Q2}?;nT.Mr?;

nT.Mu?;

IFtype=0*功能前織入*

nT.A(F)=tS.dt.A(F):t.A(F);

ELSE IFtype=1*功能后織入*

nT.A(F)=t.A(F):tS.dt.A(F);

nT.A(F)=t.A(F)|B(X)|tS.dt.A(F);

END IF

nT.Mr=t.Mr;

nT.Mu=t.Mu;

RETURNnT.

Step5. 過程層建模.當過程方面織入過程層的基本過程沒有檢測到沖突時，同樣是將過程方面融合后實施織入操作.為描述簡潔，下面僅給出過程方面的條件織入算法和過程層建模算法，過程方面融合算法與算法1的任務方面融合算法類似，過程方面的活動織入和弧織入操作與算法3的條件織入操作類似.

算法3. 條件織入操作Condition_Weaving.

輸入:p,pS;

輸出:nP=(C,A;F,M0).

nP.C?;nP.A?;nP.F?;nP.M0?;

nP.Cp.C∪pS.dp.C-{kp};

nP.Ap.A∪pS.dp.A;

IFkp?M0THEN

nP.M0p.M0;

ELSE

nP.M0M0∪pS.dp.?Ae-{kp};

END IF

RETURNnP.

算法4. 過程層建模Nprocess_Modeling.

輸入:P,NP;

輸出:NP.

KpS1.kp∪pS2.kp∪…∪pSm.kp;

FOR eachk∈KDO

FOR 同類型過程方面

調用NProcess_Merging();*NProcess_Merging()完成過程方面融合操作*

END FOR

FOR 不同類型過程方面

IFConflict=0

IFpS.kp∈p.A*活動織入*

調用Activity_Weaving(p,pS)

ELSE IFpS.kp∈p.F*弧織入*

調用Flow_Weaving(p,pS)

調用Condition_Weaving(p,pS)

END IF

ELSE

輸出沖突類型、位置、pS.idp;

END IF

END FOR

END FOR

RETURNNP.

Step6. 全局層建模.過程層建模將產生新的NFR過程，此時，全局層建模是識別所有的NFR過程、軟件過程(沒有織入過程方面的基本過程)以及過程之間的包含關系.通過全局層模型，建模者可以掌握基本模型的變化以及新模型的整體架構.

基于上述面向非功能需求的軟件過程建模方法，我們實現了一個建模輔助工具NPAT(non-functional requirements oriented process aided tool)，NPAT基于Petri網建模與分析開源工具PIPE2[30]，使用插件技術實現NFR方面的織入與沖突檢測，擴展NPAT后的建模流程如圖10所示，NPAT的實現效果參見第5節案例分析.

Fig. 10 The modeling flow of NPAT.圖10　NPAT建模流程

5案例分析

第三方認證中心軟件SIS在2004年開發完成并投入使用，經過多年對SIS軟件持續不斷的維護，現提出對其進行演化的新需求，面向此需求我們對SIS軟件的演化過程進行建模.1)使用軟件演化過程建模方法[11]建模基本模型;2)針對SIS軟件的非功能需求，考慮到認證中心提供網絡身份認證服務，是一個具有權威性和公正性的第三方可信機構、是所有網上安全活動的核心環節，SIS軟件作為可信第三方認證中心的核心軟件，負責完成認證中心提供的所有服務，對任何個人或企業甚至一個地區來說，一個安全和值得信賴的網絡環境依賴于SIS軟件的可信性，因此，項目組對SIS軟件的演化提出了如表2所示的非功能需求并從過程策略知識庫中選取了相應的過程策略.

基于選取的表2中的44項過程策略，下面使用抽象數據類型表示方法對其中的“功能分析”、“可靠性建模”和“可靠性預測”活動進行定義，其余NFR活動定義類似，在此省略.其中，活動定義中的謂詞符號和數據類型使用軟件演化過程建模方法[11]中給出的定義.

NFR_ACTIVITY Functional_Analysis

{ IMPORTS

Requirements: Requirement_Type;

Design: Design_Type;

System_for_Analysis: System_Type;

Analysis_Request: STRING;

EXPORTS

Analysis_Report: Analysis_Report_Type;

BODY

Function_analysis;

} NFR_ACTIVITYFunctional_Analysis.

Table 2Non-Functional Requirements and Corresponding

Activities of SIS Software

表2　SIS軟件的非功能需求和過程策略

NFR_ACTIVITYReliability_Modeling

{ IMPORTS

Problem_Report,Modification_Request:

STRING;

Analysis_Report: Analysis_Report_Type;

EXPORTS

Reliability_Model: Reliability_Model _Type;

BODY

Reliability_modeling;

} NFR_ ACTIVITYReliability_Modeling.

NFR_ACTIVITYReliability_Forecasting

{ IMPORTS

Reliability_Model: Reliability_Model _Type;

EXPORTS

Problem_Report: STRING;

Analysis_Report: Analysis_Report_Type;

BODY

Reliability_forecasting;

} NFR_ACTIVITYReliability_Forecasting.

根據44個NFR活動的不同粒度，我們定義了32個任務方面和12個過程方面，其中，“可靠性建模”和“可靠性預測”活動細化為任務，對應的任務方面定義如下，其余任務方面定義類似，在此省略.

tS_Reliability_Modeling=(idt,dt,kt,type)

idt=Reliability_modeling;

vdt=({Q1},{Q2})

Q1=(Rea(Modification_Request) or

Rea(Problem_Report)) and

Rea(Analysis_Report);

Q2=Rea(Reliability_Model);

kt={Problem_Modification_Analysis.

Verifying.A(F)};

type=0.*順序前織入*

tS_Reliability_Forecasting=(idt,dt,kt,type)

idt=Reliability_forecasting;

dt=({Q1},{Q2})

Q1=Rea(Reliability_Model);

Q2=Doc(Analysis_Report) or

Doc(Problem_Report);

kt={Problem_Modification_Analysis.

Verifying.A(F)};

type=0.*順序前織入*

“可靠性建模”和“可靠性預測”任務方面在同一切點同類型織入，由于它們之間有數據依賴關系，即：“可靠性預測”依賴“可靠性建模”輸出的可靠性模型實施可靠性預測，因此，以“可靠性建模”在“可靠性預測”之前的順序織入基本模型的基本任務Verifying：

nT_Verifying=({Q1},{Q2},Mi,Mo)

A(F)=({Q1},{Q2}):

{PRECONDITION(Rea(Problem_Report)

orRea(Modification_Request)) andRea

(Analysis_Report);

POSTCONDITIONRea(Reliability_Model)};

{PRECONDITIONRea(Reliability_Model);

POSTCONDITIONDoc(Analysis_Report) orDoc(Problem_Report)};

{PRECONDITIONRea(Problem_Report);

POSTCONDITIONDoc(Replicating_Report) orDoc(Verifying_Report)};

Mi={Start};

Mo={(Problem_Modification_Analysis(0),Finish)}.

而“功能分析”活動定義為過程方面：

pS_Functional_Analysis=(idp,dp,kp,type)

idp=Function_analysis;

dp=(C,A,F,Ae,Ax);

C={fa1,fa2};

A={Functional_Analysis};

F={(fa1,Functional_Analysis),

(Functional_Analysis,fa2)};

Ae={Functional_Analysis};

Ax={Functional_Analysis};

kp={c1};

type=2.*條件周圍織入操作*

其他過程方面定義類似在此省略，下面我們使用NPAT將定義的過程方面織入基本模型的基本過程SIS_Process和其子過程Design_Evolution_Package，在織入過程中，當NPAT檢測到如圖11所示的沖突提示消息時，根據提示修改過程方面，直至消解所有沖突后實施過程方面織入，得到織入后模型分別如圖12和圖13所示，為區分基本過程與織入方面，方面中活動名稱英文用粗體表示，增加的虛活動vai(1≤i≤n)僅有傳遞托肯的作用.

案例分析結果表明，使用面向方面方法分離基本軟件過程模型和面向非功能需求的過程策略有3項優勢：1)有利于幫助建模組更好地完成建模工作，在對基本模型進行建模時不需要考慮軟件的非功能需求，而對非功能需求建模時已有基本模型可以參考，有效地分離關注點不僅可以讓建模組負責不同領域的成員能夠更好地完成自己的工作，同時也讓建模組成員之間的協作更加容易；2)分離后的基本模型和面向非功能需求的過程策略都更利于在其他項目中重用；3)分離有利于柔性建模，可以讓非功能需求的織入更加靈活且更利于按需剪裁和改進.

Fig. 11　Conflict message.圖11　沖突提示消息

Fig. 12　SIS_NProcess.圖12　SIS_NProcess

Fig. 13　NDesign_Evolution_Package.圖13　NDesign_Evolution_Package

6總結與展望

軟件過程是提高軟件質量和改善軟件開發及演化的重要工具[31-33].Boehm在文獻[34]中提到，正因為對軟件不斷增長的需求，軟件過程將在未來20年繼續被研究和改進.

本文通過面向方面方法、面向軟件非功能需求定義方面，將方面編織入基本軟件過程模型，提出非功能需求可定制的軟件過程建模方法.本文的主要貢獻如下：

1) 定制非功能需求的軟件過程建模

面向非功能需求定制軟件過程建模的主要目的是面向非功能需求建立軟件過程的抽象模型，通過對該抽象模型的定義有助于更好地理解將要開發軟件的質量需求，同時，通過模擬軟件過程模型指導實際軟件生產活動，分析軟件過程中潛在的問題，可以促進過程的不斷改進并最終保證軟件的質量需求能夠得以滿足.方面與基本模型的分離與按需織入實現了軟件過程建模的高內聚低耦合.

2) 面向方面編織沖突的控制與檢測

為防止方面織入干擾基本模型或者其他方面，針對方面間沖突以及方面與基本模型間沖突，本文提出沖突控制及檢測方法.另外，為了從技術上有效地支持軟件過程建模并防止沖突發生，我們開發了建模輔助工具NPAT.

今后，在4個方面還需進一步開展相關研究工作：1)軟件演化過程建模方法[11]使用的主要形式化語言是Petri網，本文基于這個方法提出的擴展方法目前僅限于支持使用Petri網建模軟件過程的方法，下一步工作還需要探索如何擴展使用其他建模語言的建模方法;2)提升軟件質量，技術和過程是相輔相成的，過程的執行需要技術的支持，技術的使用需要過程為載體，本文主要探討的是基于過程改進來保證軟件質量，而輔助使用提升軟件質量的技術也是必需的，因此，下一步工作將研究如何通過技術及過程的結合來全面支持高質量軟件生產及演化;3)方面的編織有好的改進作用也有可能起到相反的阻礙作用，或者沒有任何作用，為此，對NFR方面的織入需要進一步驗證方面的織入在不影響模型執行的前提下按照非功能需求的滿足度確實可以提升軟件的質量，即對方面進行追蹤及驗證;4)軟件非功能需求依賴于系統上下文，基于非功能需求選取過程策略應解決可配置的問題，而且，NFR活動的輸入輸出資源也存在調度管理和占用沖突解決等問題，因此，下一步工作將對軟件非功能需求的依賴關系進行分析和權衡處理，并根據權衡處理結果提出可配置的過程策略選取方法，另外，對NFR活動的輸入輸出資源提出調度管理以及占用沖突的解決方法以進一步提升本文方法的實際可操作性.

參考文獻

[1]Lyu R. Handbook of Software Reliability Engineering[M]. Los Alamitos, CA: IEEE Computer Society, 1996

[2]Musa D. Software Reliability Engineering[M]. New York: McGraw-Hill, 1999

[3]Anderson R. Security Engineering[M]. New York: John Wiley & Sons, 2008

[4]Ericson A. Hazard Analysis Techniques for System Safety[M]. New York: John Wiley & Sons, 2005

[5]United States Department of Defense. Standard practice for system safety (MIL-STD-882D)[S]. Washington: United States Department of Defense, 2000

[6]Nielsen J. Usability Engineering[M]. London: Academic Press Limited, 1994

[7]Boehm B, In H. Identifying quality-requirement conflicts[J]. IEEE Software, 1996, 13 (2): 25-35

[8]Howard M, Leblanc D. Writing Secure Code[M]. Washington: Microsoft Press, 2002

[9]Howard M, Lipner S. The Secure Development Life-Cycle[M]. Washington: Microsoft Press, 2006

[10]Li Mingshu, Yang Qiusong, Zhai Jian. Systematic review of software process modeling and analysis[J]. Journal of Software, 2009, 20(3): 524-545 (in Chinese)(李明樹, 楊秋松, 翟健. 軟件過程建模方法研究[J]. 軟件學報, 2009, 20(3): 524-545)

[11]Li Tong. An Approach to Modelling Software Evolution Processes[M]. Berlin: Springer, 2008

[12]Jin Zhi, Liu Lin, Jin Ying. Software Requirements Engineering: Principles and Methods[M]. Beijing: Science Press, 2008 (in Chinese)(金芝, 劉璘, 金英. 軟件需求工程: 原理和方法[M]. 北京: 科學出版社, 2008)

[13]Viega J. The CLASP application security process[EBOL]. Los Angeles: Secure Software Inc, 2005[2015-02-06]. http:www. ida.liu.se～TDDC90papersclasp_external.pdf

[14]Beznosov K, Kruchten P. Towards agile security assurance[C]Proc of the New Security Paradigms Workshop (NSPW’04). New York: ACM, 2004: 47-54

[15]European Union. SecureChange project[EBOL]. (2012)[2015-02-06]. http:www.secu rechange.eu

[16]Ericson C A. Hazard Analysis Techniques for System Safety[M]. New York: John Wiley & Sons, 2005

[17]Roubtsova E E, Aksit M. Extension of Petri nets by aspects to apply the model driven architecture approach[C]Proc of the 1st Int Workshop on Aspect-Based and Model-Based Separation of Concerns in Software Systems (ABMB’05). Amsterdam: Elsevier, 2005: 1-15

[18]Xu Dianxiang, Nygard K E. Threat-driven modeling and verification of secure software using aspect-oriented Petri nets[J]. IEEE Trans on Software Engineering, 2006, 32(4): 265-278

[19]Guan Lianwei, Li Xingyu, Hu Hao, et al. A Petri net-based approach for supporting aspect-oriented modeling[J]. Frontiers of Computer Science in China, 2008, 2(4): 413-423

[20]Fu Zhitao. Research on aspect-oriented software evolution processes[D]. Kunming: Yunnan University, 2010 (in Chinese) (付志濤. 面向方面的軟件演化過程研究[D]. 昆明: 云南大學, 2010)

[21]Molderez T, Meyers B, Janssens D, et al. Towards an aspect-oriented language module: Aspects for Petri nets[C]Proc of the 7th Workshop on Domain-Specific Aspect Languages. New York: ACM, 2012: 21-26

[22]Durr P, Bergmans L, Akit M. Static and dynamic detection of behavioral conflicts between aspects[J]. Runtime Verification, 2007, 1: 38-50

[23]Kiczales G, Hilsdale E, Hugunin J, et al. An overview of AspectJ[C]Proc of the European Conf on Object-Oriented Programming (ECOOP’01). Kaiserslautern, Germany: AITO, 2001: 327-353

[24]Kniesel G, Bardey U. An analysis of the correctness and completeness of aspect weaving[C]Proc of the 13th Working Conf on Reverse Engineering (WCRE’06). Piscataway, NJ: IEEE, 2006: 324-333

[25]Kniesel G. Detection and resolution of weaving interactions[G]LNCS 5490: Trans on Aspect-Oriented Software Development. Berlin: Springer, 2009: 135-186

[26]Dinkelaker T, Erradi M, Ayache M. Using aspect-oriented state machines for detecting and resolving feature interactions[J]. Computer Science and Information Systems, 2012, 9(3): 1045-1074

[27]Wu Zhehui. Introduction to Petri Net[M]. Beijing: China Machine Press, 2006 (in Chinese) (吳哲輝. Petri網導論[M]. 北京: 機械工業出版社, 2006)

[28]Yuan Chongyi. Petri Net Principles and Applications[M]. Beijing: Publishing House of Electronics Industry, 2005 (in Chinese) (袁崇義. Petri網原理與應用[M]. 北京: 電子工業出版社, 2005)

[29]Dai Fei. An approach to verifying software evolution process models based on EPMM[D]. Kunming: Yunnan University, 2011(in Chinese)(代飛. 基于EPMM的軟件演化過程模型驗證[D]. 昆明: 云南大學, 2011)

[30]Sourceforge. PIPE2 (Platform Independent Petri Net Editor Beta)[CPOL].[2014-06-01]. http:pipe2.sourceforge.net

[31]Osterweil L J. Software processes are software too[C]Proc of the 9th Int Conf on Software Engineering (ICSE’87). New York, ACM, 1987: 2-13

[32]Osterweil L J. Software processes are software too, revisited: An invited talk on the most influential paper of ICSE 9[C]Proc of the 19th Int Conf on Software Engineering (ICSE’97). Berlin: Springer, 1997: 540-548

[33]Osterweil L J. Improving the quality of software quality determination processes[C]Proc of the Working Conf on the Quality of Numerical Software, Assessment and Enhancement. New York: ACM, 1996: 90-105

[34]Boehm B. The future of software processes[G]LNCS 3840: Proc of the Int Software Process Workshop (SPW’05). Berlin: Springer, 2006: 10-24

Zhang Xuan, born in 1978. PhD and associate professor in Yunnan University. Member of China Computer Federation. Her main research interests include software process, requirements engineering, aspect-oriented software development and formal method.

Li Tong, born in 1963. PhD and professor in Yunnan University. Senior member of China Computer Federation. His main research interests include software engineering, software process, software evolution, and formal method (tli@ynu.edu.cn).

Wang Xu, born in 1976. PhD and assistant professor in Yunnan University. His main research interests include business process management, monetary economics and banking, and financial security (wangxu@ynu.edu.cn).

Dai Fei, born in 1982. PhD and associate professor in Yunnan University. Member of China Computer Federation. His main research interests include software process, business process, and process algebra (feidai@ynu.edu.cn).

Xie Zhongwen, born in 1982. PhD and assistant professor in Yunnan University. Member of China Computer Federation. His main research interests include software evolution and requirements engineering (xiezw56@126.com).

Yu Qian, born in 1975. PhD and assistant professor in Yunnan University. Member of China Computer Federation. Her main research interests include software process and formal method(yuqian@ynu.edu.cn).

收稿日期：2015-02-09；修回日期：2015-08-11

基金項目：國家自然科學基金項目(61262025，61502413，61379032，61262024)；云南省科技計劃項目(2016FB106)；云南省教育廳科學研究基金重點項目(2015Z020，2013A056)；云南省軟件工程重點實驗室開放基金項目(2015SE202，2012SE308)； 云南大學高水平創新團隊計劃“軟件工程創新團隊”項目(XT412011)，云南大學“中青年骨干教師培養計劃”項目(XT412003)；云南大學人文社科基金項目(13YNUHSS007)

中圖法分類號TP311.5

Non-Functional Requirements Oriented Software Process Modeling

Zhang Xuan1,2, Li Tong1,2, Wang Xu3, Dai Fei1,2, Xie Zhongwen1,2, and Yu Qian1,21(SchoolofSoftware,YunnanUniversity,Kunming650091)2(KeyLaboratoryofSoftwareEngineeringofYunnan(YunnanUniversity),Kunming650091)3(SchoolofEconomics,YunnanUniversity,Kunming650091)

AbstractThe qualities of software relate to their synonym of non-functional requirements (NFRs) and mostly depend on the software processes. Based on this viewpoint, collecting process strategies from different software engineering processes and using aspect-oriented modeling, an approach to modeling NFRs-oriented software processes is proposed. The purpose of the approach is to ensure the development or evolution of high quality software through the whole life cycle of the software. First, a knowledge base of process strategies is created to store the activities for ensuring the software qualities. Based on these strategies and using aspect-oriented approach, corresponding aspects are defined to be composed into the base software process models. The need for these aspects is based primarily on the factor that the activities for NFRs and the base process models can be created separately and easily to be composed later. Besides, the conflicts between multi-aspects and between aspects and base models are detected and controlled. Second, a modeling aided tool NPAT (non-functional requirements-oriented processes aided tool) is developed to support the modeling of NFR-oriented software processes. Finally, the theory, the approach and the tool were used in a case study. Through the case study, the theory and the approach are proved to be feasible and the tool is proved to be effective. The NFRs-oriented software process modeling approach can help an organization provide a focus for enhancing software qualities by adding the NFR activities to the software processes.

Key wordssoftware non-functional requirement; software process; aspect-oriented modeling; Petri nets; conflict

This work was supported by the National Natural Science Foundation of China (61262025,61502413,61379032,61262024), the Science and Technology Foundation of Yunnan Province (2016FB106), the Science Foundation of Yunnan Educational Committee (2015Z020，2013A056), the Science Foundation of Key Laboratory of Software Engineering of Yunnan Province (2015SE202,2012SE308), the Software Engineering Innovative Research Team Funding of Yunnan University High Level Innovative Team Plan (XT412011), the Young Teachers Special Training Program Funding of Yunnan University (XT412003), and the Social Science Foundation of Yunnan University (13YNUHSS007).