面向软件非功能需求的软件过程建模方法

张　璇　李　彤　王　旭　代　飞　谢仲文　于　倩

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).