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

1(云南大學(xué)軟件學(xué)院　昆明　650091)2(云南省軟件工程重點(diǎn)實(shí)驗(yàn)室(云南大學(xué))　昆明　650091)3　　　(云南大學(xué)經(jīng)濟(jì)學(xué)院　昆明　650091)

?

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

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

1(云南大學(xué)軟件學(xué)院昆明650091)2(云南省軟件工程重點(diǎn)實(shí)驗(yàn)室(云南大學(xué))昆明650091)3(云南大學(xué)經(jīng)濟(jì)學(xué)院昆明650091)

(zhxuan@ynu.edu.cn)

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

關(guān)鍵詞軟件非功能需求;軟件過程;面向方面建模;Petri網(wǎng);沖突

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

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

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

1相關(guān)工作

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

1.1軟件質(zhì)量與軟件過程

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

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

另外，本文使用面向方面方法擴(kuò)展軟件演化過程建模方法[11]，由于軟件演化過程建模方法基于的主要形式化方法是Petri網(wǎng)，因此本文對面向方面方法和面向方面Petri網(wǎng)領(lǐng)域的相關(guān)研究進(jìn)行介紹.

1.2面向方面方法相關(guān)研究

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

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

2面向軟件非功能需求的軟件過程建?？蚣?/p>

本文使用指定階段軟件開發(fā)方法，在軟件生命周期過程中的特定階段指定執(zhí)行一些有助于提升軟件質(zhì)量的活動(dòng)，為表示這些活動(dòng)是面向軟件非功能需求，與軟件質(zhì)量有關(guān)的活動(dòng)，本文后續(xù)內(nèi)容中使用NFR活動(dòng)來表示這類特殊指定的活動(dòng).

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

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

在軟件過程建模領(lǐng)域，基于Petri網(wǎng)擴(kuò)展面向?qū)ο蠹夹g(shù)和霍爾邏輯，軟件演化過程建模方法[11]可以形式化地定義軟件過程中所有任務(wù)、活動(dòng)和過程的結(jié)構(gòu)及行為.軟件過程建模方法是本文用于建?；灸Ｐ偷墓ぞ?，在此基礎(chǔ)上，針對不同軟件的不同非功能需求，我們使用面向方面方法實(shí)施擴(kuò)展，提出面向軟件非功能需求的軟件過程建模方法.下面首先介紹過程策略知識(shí)庫的構(gòu)建.

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

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

Table 1　Non-Functional Requirements-Oriented NFR Activities

Continued (Table 1)

面向軟件非功能需求的NFR活動(dòng)并非一成不變，隨著時(shí)代的發(fā)展、技術(shù)的進(jìn)步以及不同項(xiàng)目需要和不同專家建議，NFR活動(dòng)應(yīng)該根據(jù)軟件具體需要?jiǎng)討B(tài)調(diào)整.

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

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

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

基于分層的思想，軟件演化過程建模方法定義了軟件過程建?？蚣躘11]，即當(dāng)一個(gè)高層的活動(dòng)細(xì)化為一個(gè)軟件過程或者多個(gè)任務(wù)時(shí)，軟件過程模型的層次結(jié)構(gòu)就開始形成.面向非功能需求的軟件過程建模保持原有框架結(jié)構(gòu)實(shí)施面向方面擴(kuò)展，擴(kuò)展后的框架如圖1所示.

面向非功能需求的軟件過程建?？蚣艿暮诵臄U(kuò)展源是NFR活動(dòng)，按照軟件演化過程建模方法中活動(dòng)的定義，NFR活動(dòng)的形式化定義如下：

定義1. 一個(gè)NFR活動(dòng)是一個(gè)四元組nA=(I,O,L,B)，其中：I，O，L是活動(dòng)體B操作的輸入數(shù)據(jù)結(jié)構(gòu)、輸出數(shù)據(jù)結(jié)構(gòu)和本地?cái)?shù)據(jù)結(jié)構(gòu)，活動(dòng)體B是一個(gè)軟件過程或者一個(gè)任務(wù)集合.一個(gè)NFR活動(dòng)定義為一個(gè)類，稱為NFR活動(dòng)類，當(dāng)NFR活動(dòng)執(zhí)行時(shí)，創(chuàng)建NFR活動(dòng)對象.

如果一個(gè)NFR活動(dòng)細(xì)化為一個(gè)過程，這個(gè)過程就封裝為過程方面，如果一個(gè)NFR活動(dòng)細(xì)化為一個(gè)任務(wù)集合，其中的每一個(gè)任務(wù)都封裝為任務(wù)方面，過程方面和任務(wù)方面統(tǒng)稱為NFR方面.

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

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

1)id是NFR方面的標(biāo)識(shí)；

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

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

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

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

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

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

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

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

3)A是活動(dòng)的有限集，?a∈A稱為一個(gè)活動(dòng)，a的發(fā)生稱為a的執(zhí)行或者點(diǎn)火；

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

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

過程通知是一個(gè)沒有格局的基本Petri網(wǎng)(本文后續(xù)內(nèi)容所有相關(guān)Petri網(wǎng)的符號定義使用吳哲輝在其文獻(xiàn)[27]中的定義)，沒有格局意味著過程通知中的活動(dòng)沒有發(fā)生權(quán)，只有將過程方面編織入基本模型的過程(下面簡稱為基本過程)后，其中的活動(dòng)在編織后的過程模型格局中才有發(fā)生權(quán).過程通知的建模基于軟件演化過程建模方法中基本塊和過程包定義[11]，應(yīng)用白盒建模及黑盒建模方法實(shí)現(xiàn).當(dāng)應(yīng)用白盒方法建模時(shí)，過程通知中的一個(gè)活動(dòng)細(xì)化為一個(gè)基本塊；而應(yīng)用黑盒方法建模時(shí)，活動(dòng)細(xì)化為一個(gè)過程包，隱藏其內(nèi)部結(jié)構(gòu).

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

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

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

2) 活動(dòng)切點(diǎn)集合{p.a|a∈A}；

3) 弧切點(diǎn)集合{p.f|f∈F}.

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

定義6. 一個(gè)任務(wù)方面是一個(gè)四元組tS=(idt,dt,kt,type)，其中：idt是任務(wù)方面標(biāo)識(shí)，dt是任務(wù)通知，kt是任務(wù)切點(diǎn)，type描述通知dt的織入類型.

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

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

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

任務(wù)通知是一個(gè)不帶消息的2-斷言，即未編織的任務(wù)通知僅定義功能，沒有發(fā)生權(quán)，只有將任務(wù)方面編織到基本任務(wù)中，當(dāng)任務(wù)方面接收到消息開始執(zhí)行時(shí)，任務(wù)通知才能隨之執(zhí)行.當(dāng)然，任務(wù)通知的功能也可以基于軟件演化過程建模方法[11]分解為順序、選擇或者循環(huán)結(jié)構(gòu).

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

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

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

Step1. 初始化.初始化工作是建立一張編織計(jì)劃表WeavePlan，存儲(chǔ)方面織入切點(diǎn)及類型，如圖2所示：

Fig. 2　WeavePlan.圖2　編織計(jì)劃表

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

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

Step2. 方面融合.同切點(diǎn)同類型NFR方面織入基本模型之前必須先融合然后才能織入，因?yàn)樵诿嫦蚍矫娣椒ㄖ校磺悬c(diǎn)織入的多個(gè)方面間會(huì)出現(xiàn)相互排斥、執(zhí)行順序不確定或者一個(gè)方面的執(zhí)行受另一個(gè)方面約束等方面間沖突問題，而這類沖突問題是方面間依賴關(guān)系引起的，因此，對于同切點(diǎn)同類型NFR方面，需要根據(jù)方面間依賴關(guān)系首先實(shí)施融合操作.

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

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

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

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

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

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

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

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

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過程構(gòu)成.NFR過程是由基本過程編織了過程方面而得到的，一個(gè)NFR過程可以由子軟件過程和子NFR過程構(gòu)成.沒有擴(kuò)展過程方面的基本過程仍由其原來的子軟件過程構(gòu)成.

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

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

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

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

3消解方面合成沖突

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

針對2.2節(jié)提出的面向軟件非功能需求的軟件過程建?？蚣?，下面研究過程方面和任務(wù)方面織入基本模型時(shí)，方面間、方面與基本模型間的沖突.

3.1方面間沖突

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

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

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

1) 通知為過程通知，通知中的活動(dòng)ai和aj之間有數(shù)據(jù)依賴關(guān)系aiδdaj，有M[ai>(活動(dòng)ai在標(biāo)識(shí)M有發(fā)生權(quán)記為M[ai>，其中，標(biāo)識(shí)M是Petri網(wǎng)的運(yùn)行狀態(tài)[27])但M[aj>，M[ai>M′→M′[aj>(活動(dòng)ai在標(biāo)識(shí)M發(fā)生得到一個(gè)新的標(biāo)識(shí)M′記為M[ai>M′[27])；

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

則稱方面編織是完整的.

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

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

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

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

則稱方面編織是正確的.

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

3.2方面與基本模型間沖突

在任務(wù)層，當(dāng)任務(wù)方面織入基本模型的基本任務(wù)時(shí)，由于我們僅擴(kuò)展基本任務(wù)的功能，不改變基本任務(wù)的消息機(jī)制，不會(huì)引入沖突.因此，下面我們僅對過程方面與基本模型的基本過程間的沖突進(jìn)行研究.

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

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

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

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

根據(jù)上述對沖突類型的分析，結(jié)構(gòu)沖突僅與過程模型的拓?fù)浣Y(jié)構(gòu)有關(guān)，與過程模型的初始格局無關(guān)，而格局反映了過程的運(yùn)行狀態(tài)，與運(yùn)行狀態(tài)有關(guān)的沖突我們稱為性質(zhì)沖突.為建立方面織入無沖突的基線，根據(jù)上述對潛在沖突過程片段的定義，我們提出如下無結(jié)構(gòu)沖突和無性質(zhì)沖突的定義：

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

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

為建立過程方面織入無行為沖突的基線，下面首先對基本過程中活動(dòng)的4類行為關(guān)系進(jìn)行定義：

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

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

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

則稱ai和aj之間是順序行為關(guān)系.當(dāng)活動(dòng)序列σ長度為0時(shí)，M[ai>M′→M′[aj>，稱ai和aj是直接順序行為關(guān)系；當(dāng)活動(dòng)序列σ長度不為0時(shí)，稱ai和aj是間接順序行為關(guān)系.

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

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

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

則稱ai和aj之間是選擇行為關(guān)系.當(dāng)活動(dòng)序列σ長度為0時(shí)，有M[ai>且M[aj>，M[ai>M″ →M″[aj>或M[aj>M′→M′[ai>，稱ai和aj是直接選擇行為關(guān)系；當(dāng)活動(dòng)序列σ長度不為0時(shí)，稱ai和aj是間接選擇行為關(guān)系.

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

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

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

則稱ai和aj之間是并發(fā)行為關(guān)系.當(dāng)活動(dòng)序列σ長度為0時(shí)，有M[ai>且M[aj>，M[ai>M2→M2[aj>或者M(jìn)[aj>M4→M4[ai>，稱ai和aj是直接并發(fā)行為關(guān)系；當(dāng)活動(dòng)序列σ長度不為0時(shí)，稱ai和aj是間接并發(fā)行為關(guān)系.

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

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

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

則稱ai和aj之間是迭代行為關(guān)系.當(dāng)活動(dòng)序列σ長度為0時(shí)，M[ai>M′→M′[aj>M?[ai>，稱ai和aj是直接迭代行為關(guān)系；當(dāng)活動(dòng)序列σ長度不為0時(shí)，稱ai和aj是間接迭代行為關(guān)系.

基于上述活動(dòng)間行為關(guān)系的定義，當(dāng)過程方面織入基本過程時(shí)，無行為沖突定義如下：

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

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

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

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

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

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

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

Fig. 5　Before activity weaving.圖5　活動(dòng)前織入操作

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

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

Fig. 6　After activity weaving.圖6　活動(dòng)后織入操作

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

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

3.3面向方面沖突檢測

本文繼續(xù)使用面向方面方法中的方面檢測沖突，用于檢測沖突的方面定義為沖突檢測方面，沖突檢測方面的切點(diǎn)定義為沖突模式，沖突檢測方面根據(jù)此沖突模式進(jìn)行沖突檢測，當(dāng)切點(diǎn)匹配存在沖突的連接點(diǎn)時(shí)檢測到?jīng)_突，此時(shí)，沖突通知阻止織入過程方面并記錄沖突類型、位置和導(dǎo)致沖突產(chǎn)生的過程方面，為建模者消解沖突提供相關(guān)信息.沖突檢測方面定義如下：

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

1)id是沖突檢測方面標(biāo)識(shí)，用于標(biāo)識(shí)不同類型的沖突檢測方面；

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

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

下面我們基于過程方面織入基本過程可能產(chǎn)生的結(jié)構(gòu)和性質(zhì)沖突，定義沖突檢測方面.

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

Fig. 7　Detection aspects for structure conflict.圖7　結(jié)構(gòu)沖突檢測方面

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

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

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

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

面向軟件非功能需求，從過程策略知識(shí)庫選取過程策略，解決方面合成沖突并基于過程建?？蚣艿倪^程建模流程如圖9所示，首先從活動(dòng)層建模開始，然后根據(jù)活動(dòng)分解的不同粒度，進(jìn)行任務(wù)層建模和過程層建模;最后，完成全局層建模.

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

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

Step2. 活動(dòng)層建模.基于Step1得到的過程策略實(shí)施NFR活動(dòng)建模，即在活動(dòng)層設(shè)計(jì)NFR活動(dòng)，定義NFR活動(dòng)的輸入、輸出、本地?cái)?shù)據(jù)結(jié)構(gòu)及活動(dòng)體，按照分解粒度不同，將活動(dòng)體定義為一個(gè)軟件過程或者一個(gè)任務(wù)集合，并在此基礎(chǔ)上定義過程方面和任務(wù)方面.

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

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

算法1. 任務(wù)方面融合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中所有任務(wù)的數(shù)據(jù)依賴關(guān)系RD和控制依賴關(guān)系RC;

IFl個(gè)方面存在依賴關(guān)系

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

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

END IF

調(diào)用Constructing_TDG(tS1.dt1∪tS2.dt2∪…∪tSl.dtl,input(tSi),output(tSi),RD,RC,TDG);*Constructing_TDG()是文獻(xiàn)[11]中構(gòu)造依賴圖的算法，TDG是表示任務(wù)依賴關(guān)系的依賴圖*

轉(zhuǎn)換TDG為任務(wù)通知dt;

idt0;*0表示融合的任務(wù)方面標(biāo)識(shí)*

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

type=typel;

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

FORl=1 TOm

tSl.ktltSl.ktl-kt;

END FOR

算法2. 任務(wù)方面織入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. 過程層建模.當(dāng)過程方面織入過程層的基本過程沒有檢測到?jīng)_突時(shí)，同樣是將過程方面融合后實(shí)施織入操作.為描述簡潔，下面僅給出過程方面的條件織入算法和過程層建模算法，過程方面融合算法與算法1的任務(wù)方面融合算法類似，過程方面的活動(dòng)織入和弧織入操作與算法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 同類型過程方面

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

END FOR

FOR 不同類型過程方面

IFConflict=0

IFpS.kp∈p.A*活動(dòng)織入*

調(diào)用Activity_Weaving(p,pS)

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

調(diào)用Flow_Weaving(p,pS)

調(diào)用Condition_Weaving(p,pS)

END IF

ELSE

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

END IF

END FOR

END FOR

RETURNNP.

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

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

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

5案例分析

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

基于選取的表2中的44項(xiàng)過程策略，下面使用抽象數(shù)據(jù)類型表示方法對其中的“功能分析”、“可靠性建?！焙汀翱煽啃灶A(yù)測”活動(dòng)進(jìn)行定義，其余NFR活動(dòng)定義類似，在此省略.其中，活動(dòng)定義中的謂詞符號和數(shù)據(jù)類型使用軟件演化過程建模方法[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.

根據(jù)44個(gè)NFR活動(dòng)的不同粒度，我們定義了32個(gè)任務(wù)方面和12個(gè)過程方面，其中，“可靠性建模”和“可靠性預(yù)測”活動(dòng)細(xì)化為任務(wù)，對應(yīng)的任務(wù)方面定義如下，其余任務(wù)方面定義類似，在此省略.

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.*順序前織入*

“可靠性建?！焙汀翱煽啃灶A(yù)測”任務(wù)方面在同一切點(diǎn)同類型織入，由于它們之間有數(shù)據(jù)依賴關(guān)系，即：“可靠性預(yù)測”依賴“可靠性建模”輸出的可靠性模型實(shí)施可靠性預(yù)測，因此，以“可靠性建?！痹凇翱煽啃灶A(yù)測”之前的順序織入基本模型的基本任務(wù)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)}.

而“功能分析”活動(dòng)定義為過程方面：

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，在織入過程中，當(dāng)NPAT檢測到如圖11所示的沖突提示消息時(shí)，根據(jù)提示修改過程方面，直至消解所有沖突后實(shí)施過程方面織入，得到織入后模型分別如圖12和圖13所示，為區(qū)分基本過程與織入方面，方面中活動(dòng)名稱英文用粗體表示，增加的虛活動(dòng)vai(1≤i≤n)僅有傳遞托肯的作用.

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

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

Fig. 12　SIS_NProcess.圖12　SIS_NProcess

Fig. 13　NDesign_Evolution_Package.圖13　NDesign_Evolution_Package

6總結(jié)與展望

軟件過程是提高軟件質(zhì)量和改善軟件開發(fā)及演化的重要工具[31-33].Boehm在文獻(xiàn)[34]中提到，正因?yàn)閷浖粩嘣鲩L的需求，軟件過程將在未來20年繼續(xù)被研究和改進(jìn).

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

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

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

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

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

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

參考文獻(xiàn)

[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]. 軟件學(xué)報(bào), 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]. 北京: 科學(xué)出版社, 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]. 昆明: 云南大學(xué), 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網(wǎng)導(dǎo)論[M]. 北京: 機(jī)械工業(yè)出版社, 2006)

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

[29]Dai Fei. An approach to verifying software evolution process models based on EPMM[D]. Kunming: Yunnan University, 2011(in Chinese)(代飛. 基于EPMM的軟件演化過程模型驗(yàn)證[D]. 昆明: 云南大學(xué), 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

基金項(xiàng)目：國家自然科學(xué)基金項(xiàng)目(61262025，61502413，61379032，61262024)；云南省科技計(jì)劃項(xiàng)目(2016FB106)；云南省教育廳科學(xué)研究基金重點(diǎn)項(xiàng)目(2015Z020，2013A056)；云南省軟件工程重點(diǎn)實(shí)驗(yàn)室開放基金項(xiàng)目(2015SE202，2012SE308)； 云南大學(xué)高水平創(chuàng)新團(tuán)隊(duì)計(jì)劃“軟件工程創(chuàng)新團(tuán)隊(duì)”項(xiàng)目(XT412011)，云南大學(xué)“中青年骨干教師培養(yǎng)計(jì)劃”項(xiàng)目(XT412003)；云南大學(xué)人文社科基金項(xiàng)目(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).