面向特征的软件开发(feature oriented software development,简称FOSD)^{[1, 2]}是一种面向大规模定制化软件开发的过程方法,其基本思想是:以复用为核心,将软件特征作为复用的基本单元,通过特征组合生成满足特定业务场景的软件产品.由于FOSD为大规模定制化软件的开发提供了一种有效的过程方法,近年来受到研究人员和工业实践的广泛关注^[2].

特征模型(feature model)是FOSD的核心概念和制品.该模型在特征基础上描述了领域内产品的共性和可变性(commonality and variability)^[3].特征模型主要为FOSD提供两个方面的支持:一方面支持领域可复用资产的识别和开发^[3];另一方面支持特征模型的配置,根据定制产品的需求选择合适的特征^[4].一个设计良好的特征模型,可有效提升定制产品的开发效率和质量.

随着用户需求和产品特征的不断变更,特征模型也持续演化.当前,分析特征模型演化仍然面临诸多挑战,这些挑战主要源自以下几个方面:

(1) 特征变更的“涟漪”效应(ripple effect).

特征并不是孤立存在的,它们在设计或者实现等方面都存在相关性.这些相关性使得单一特征的变更可能会传播至其他特征,形成“涟漪”效应^{[5, 6]}.由于特征模型面向重用开发,特征间的关联关系更加多样,使得其中的变更传播也更为复杂;

(2) 共性和可变性的变化.

共性和可变性是特征模型的本质,其变化也是特征模型演化的重要组成.共性和可变性设计的一个基本原则是,尽可能地识别产品共性,满足高效的复用开发^{[7, 8]}.因此,当发生特征变更时,不仅需要考虑是否有新的特征可作为产品共性,还需考虑对特征进行重构挖掘其中的共性成分;

(3) 特征模型配置的变化.

特征变更或者共性和可变性的变化都可改变特征模型的配置.由于特征模型面向不同的定制产品,更新特征模型配置应兼顾不同产品的演化需求,避免破坏相关产品.此外,为了生成有效的定制产品,特征模型的配置还应保持一致^[9].由于任意模型操作都有可能引发配置冲突^[10],因此,在分析特征模型配置变化时,还需识别其中的冲突并进行消解.

特征模型演化分析一直是FOSD研究的重点,但是已有的研究工作多以需求为基础.这些方法通常基于需求模型或者需求规约分析特征的变更,随后将分析结果迁移到特征模型中,并指明共性和可变性的变化^{[11, 12, 13]}.其中的共性和可变性分析仅仅在需求层面进行,特征模型只是用来描述这些变化.而通过特征模型表达共性和可变性变化时,变更特征引发的“涟漪”效应可导致更多的共性和可变性变化.由于需求模型和需求规约缺乏对特征和特征关联关系的描述^[14],从而无法实现对特征变更“涟漪”效应的分析,进而无法发现一些潜在的产品共性.除了上述方法以外,还有一些研究工作关注演化分析的某一个方面,例如诊断特征模型的异常或者错误^{[10, 15, 16]}.这些方法或只能检测模型的异常和错误,或只给出简单的解决方案,不能满足模型演化分析的要求.

基于上述挑战和现有研究的不足,本文提出一种特征模型扩展和演化分析方法,根据定制产品的特征变更请求,分析、识别和演化特征模型.该方法扩展了特征关联关系和特征模型演化元操作(meta-operator),通过这些扩展,实现了特征变更“涟漪”效应的分析,定位特征变更对特征模型造成的影响;发现潜在的产品共性,建立策略和半自动化的分析工具,支持共性提取和特征重构;同时,该方法还针对典型的模型配置冲突建立规则和策略,消解出现的配置冲突,维护了模型配置的一致性.为了验证该方法的可用性和有效性,我们选取一个具有代表性的软件系统进行案例分析.分析结果表明,本文所提出的方法可以用于实际项目中辅助项目人员有效分析和识别特征模型演化.

本文第1节介绍特征模型.第2节对特征模型进行扩展.第3节详细描述特征模型演化分析的过程.第4节是案例分析.第5节讨论方法的局限性以及案例分析得到的经验.第6节介绍本文的相关工作.第7节对本文进行总结.

1 特征模型

特征通常指从用户角度观察到的软件特性,其满足一个或者多个用户需求^{[3, 17]}.Kang等人首次将特征引入到了软件产品线工程(software product line engineering)中,通过特征建模,分析和描述领域的共性和可变性^[3].特征模型包含层次化的特征,并提供不同类型的关联关系约束特征的选择.图1显示了一个软件过程管理系统(简称Qone)的特征模型片段和对该片段进行配置得到的定制产品片段.

1.1 特征关联关系

在特征模型中,根据其作用的不同,可将特征关联关系划分为两类:父子约束关系和跨树约束(cross-tree constraint)关系^[18].父子约束关系描述了父子特征的配置,即,当父特征被选择时,如何选择子特征.该类型的关联关系一般包括4种类型:必选(mandatory)、可选(optional)、单选(alternative)和多选(or).跨树约束关系则约束了非父子特征之间的配置,一般包括依赖(imply)和互斥(exclude)关系.本文将这些类型的关联关系称为配置约束(configuration constraint)关系.表1详细描述了每种类型的配置约束关系,并根据图1给出了例子.

1.2 特征配置约束的一致性

在特征模型中,一个特征的选择可能受到多种配置约束关系的制约.错误或者不谨慎的配置约束关系设置可引发配置冲突或者违背特征既有的配置约束.例如,若两个特征间同时存在依赖和互斥关系,可导致分析人员无法对这两个特征进行选择.针对特征模型中可能存在的配置约束不一致问题,Maben和Guo等人总结了多种典型的配置冲突场景^{[9, 10]}.我们综合这些工作,将冲突场景归纳为5种类型.表2描述了每种类型及其相应的后果,其中的完全必选(full mandatory)特征指从该特征自身到根特征(root)路径上的每个特征都为必选特征^[9].

图2显示了每种冲突场景的例子.在图2(a)中,由于被完全必选特征f₁依赖,可选特征f₂将被强制包含在每个产品中,从而违背了该特征与父特征间的可选关系.在图2(b)中,由于与f₁互斥,f₃无法被任何产品选中.这样的特征也称为死(dead)特征^[18].在其余3种配置冲突例子中,冲突的配置约束使得无法在两个特征中做出选择.

2 扩展特征模型

特征模型的演化分析面临诸多挑战,而在前述特征模型基础上解决这些挑战,可能会导致某些重要的特征模型变化被忽略,尤其是在分析特征变更的“涟漪”效应时.本节针对该不足,补充了3种特征关联关系,并对特征模型演化元操作进行相应的扩展.

2.1 扩展特征关联关系

在特征变更的“涟漪”效应中,变更的传播主要通过特征之间的关联关系.识别不同层次、不同类型关联关系上的特征变更传播,是分析“涟漪”效应的关键.但是当前,特征模型只定义了与特征配置相关的关联关系,并未说明特征在设计等其他方面的相关性.仅从这些关联关系分析,可能导致“涟漪”效应分析存在缺失.例如,相似的特征之间也可能存在变更传播,即,当特征f_i被修改时,与f_i相似的特征也可能被修改.由于特征模型缺乏对此类关联关系的表达,从而无法在模型中识别该类的变更传播.

虽然已有很多研究工作对特征关联关系进行了扩展^{[19, 20, 21]},例如描述特征操作时或者运行时的相关性,但这些扩展仍然关注于特征配置,是对特征配置约束关系的细化,无法为“涟漪”效应分析提供更多可用的关联关系.

在分析特征关联关系时,我们受到需求关联关系相关研究的启发.由于特征是需求在系统功能层次上的表达,需求关联关系也可用于特征之间^[20].例如,相似关系描述完成任务相似的需求,也可用于关联功能相似的特征.在需求关联关系的研究中,有两个具有代表性的模型:Dahlstedt需求关联关系模型^[22]和Pohl需求关联关系模型^[23].但是,并不是所有类型的关联关系都可用于分析“涟漪”效应.根据Zhang等人对这些模型中的关联关系调查和分析的结果^[24],有3种类型的关联关系——前置(precedes)、限制(constrains)和相似(similar_to)常用于实际项目中“涟漪”效应的分析.基于该成果,我们将这3种关联关系补充到特征模型中,并重新定义:

· 前置:描述特征在业务流程中的前后关系;

· 限制:描述了一个特征约束另一个特征的功能或行为;

· 相似:描述一组功能相似或者使用相同数据的特征.

为与配置约束关系区分,我们为扩展的关联关系设计了新的符号,如图3所示,在图3(a)中,数据备份前需要设置系统采用的数据库,因此“设置数据库”前置于“备份数据”.在图3(b)中,由于只有系统授权的角色才能创建项目,因此“创建项目”受限于“设置角色和权限”;在图3(c)中,“我的风险列表”、“项目风险列表”和“风险视图”为一组相似的特征,它们都通过列表的形式展示风险.

2.2 扩展特征模型演化元操作

在演化过程中,特征模型的变化通常可通过一个或一组模型元操作表达.根据前面补充的3种关联关系,我们在现有研究的基础上^{[10, 25, 26]}对特征模型演化元操作进行了扩展.表3显示了扩展后的特征模型演化元操作.

表3从操作类型和特征关联关系类型两个维度定义了22个演化元操作,每个元操作由操作名称和目标特征构成.在配置约束关系相关的操作中:父子约束关系的插入和删除操作同时包括特征的插入和删除以及父子配置约束关系的改变,例如,InsOpt(f_i,f_j)表示为f_j插入新的可选子特征f_i;跨树约束关系相关操作关注特征间依赖或者互斥关系的改变,例如,InsImpl(f_i,f_j)表示在f_i和f_j之间插入依赖关系,使得f_i依赖f_j;扩展关联关系相关操作关注特征间前置、限制或者相似关系的改变,例如,InsSim(f_i,f_j)表示在f_i和f_j之间插入相似关系.

3 基于特征模型的演化分析

在扩展特征关联关系和演化元操作的基础上,我们设计了一个流程,实现基于特征模型的演化分析,图4显示了该流程的主要阶段和活动.该过程以特征变更请求集合为输入,这些特征变更请求来自于不同的产品,其定义如下:

定义1(特征变更请求). 一个特征变更请求(记作cr)是一个四元组:

cr=(f,f′,changType,product).

其中,

· f表示变更前的特征.当变更类型为“添加”时,f为请求添加特征的父特征.

· f'表示变更后的特征.当变更类型为“删除”时,f'为请求删除特征的父特征.

· changeType={“添加”,“修改”,“删除”}表示特征变更的类型.

· product表示提出该变更的产品.由于变更可能由多个产品同时提出,该元素为产品集合.

由于特征的添加、修改和删除总是伴随着特征关联关系的改变,因此,特征变更请求隐含变更特征与其他特征关联关系的变化.实际上,特征间关联关系的改变也可单独作为一类变更请求提出.而满足关联关系的变更,也必然导致特征的修改.例如,移除特征f_i和f_j之间的互斥关系,这两个特征之中至少一个需被修改.由于本文重点从特征的添加、修改和删除研究特征模型演化,而对特征关联关系的变更如何改变特征模型,则不在本文的研究范围内.

整个分析过程包含为3个阶段:特征变更影响定位、共性提取和模型修剪以及冲突消解.特征变更影响定位阶段分析输入特征变更对特征模型造成的影响,包括识别“涟漪”效应引发的其他特征变更,根据特征变更分析特征配置约束关系和扩展关联关系的变化;共性提取和模型修剪阶段在定位分析的基础上对插入的可选特征和形成的相似特征进行共性分析,并根据分析结果修剪特征模型;冲突消解阶段在发生配置约束变化的特征间进行配置冲突的检测和消解.分析过程结束时,输出特征模型演化操作集合.根据该集合可得到演化后的特征模型.

3.1 特征变更影响定位

本阶段的目标是分析输入特征变更对模型造成的影响,并在特征模型中进行定位,包括分析这些变更引发的“涟漪”效应、根据特征变更分析特征配置约束关系和扩展关联关系的变化.

3.1.1 “涟漪”效应分析

分析“涟漪”效应时,主要利用扩展的前置、限制和相似这3种关联关系.根据这些类型的关联关系,我们设计了规则识别受“涟漪”效应影响的特征.

规则1. 如果模型中的特征f符合下列条件之一,其可能受到“涟漪”效应影响发生变更.

· 当f的前置特征发生变更时,即,为f添加新的前置特征或者修改前置特征;

· 当限制f的特征发生变更时,即,为f添加新的限制特征,修改或者删除限制特征;

· 当与f相似的特征被修改时.

根据特征变更请求的定义,除识别受影响的特征外,还需确定这些特征的变更类型.在“涟漪”效应的相关研究中,多数工作都只识别受到影响的实体^{[27, 28, 29, 30]},并未进一步探讨实体变更的类型.通过追溯“涟漪”效应发生的过程我们发现,受影响特征的变更类型与两个因素相关:一是影响该特征的特征变更类型,二是识别该特征所依据的关联关系类型.综合这两个因素,可得到变更类型决策矩阵,见表4.

利用该矩阵,可形成如下规则:

规则2. 对于通过规则1识别的受影响特征f,其变更cr的类型可通过如下规则定义:

· 如果f受添加类型变更的影响,并通过前置或者限制关系识别,则cr的类型为修改;

· 如果f受修改类型变更的影响,并通过前置、限制或者相似关系识别,则cr的类型为修改;

· 如果f受删除类型变更的影响,并通过前置关系识别,则cr的类型为删除;

· 如果f受删除类型变更的影响,并通过限制关系识别,则cr的类型为修改.

根据规则1和规则2分析后,可将分析结果提交给项目分析人员确认,保证结果的准确性.图5显示了两个“涟漪”效应分析的例子:图5(a)中的特征来自于图3(c),当“项目风险列表”被修改时,与之相似的两个特征“我的风险列表”和“风险视图”也需被修改;图5(b)中,“定时任务”前置于“定时任务消息”,当删除“定时任务”时,“定时任务消息”也需被删除.

3.1.2 特征配置约束关系分析

特征的变更,改变了特征模型的配置.由于特征变更请求来自于不同的定制产品,直接根据这些请求进行模型操作,可能会破坏其他产品所需的特征配置.例如,删除特征“定时任务”由某一产品提出,如果直接从模型中删除该特征,其他需要该特征的产品则无法得到满足.为了避免此类现象的发生,我们根据不同类型的特征变更定义了配置更新策略,从而兼顾不同产品对特征模型的配置要求.

· 策略1:当cr的类型为添加时,直接将请求添加的特征插入到特征模型中,定义配置约束关系.

· 策略2:当cr的类型为修改时,将变更后特征插入到特征模型中,同时保留变更前特征.通过定义或者更新配置约束关系,满足不同产品对二者的需求.

· 策略3:当cr的类型为删除时,更新请求删除特征的配置约束关系,而不是直接从模型中移除该特征.

根据不同的更新策略,我们进一步根据特征变更的上下文设计了详细的规则为变更涉及特征定义或者更新配置约束关系.图6通过图形化的方式描述了该规则.

规则3. 对于一个特征变更请求cr,变更前特征f和变更后特征f'的配置约束关系可通过如下规则定义或者更新:

· 当cr的类型为添加时,如果f的子特征不为单选或者多选特征组,则可将f'插入为f的可选子特征;反之,将f'直接插入到特征组中.

· 当cr的类型为修改时,可将f'插入到f的邻居节点:

1) 如果f为必选特征,则f和f'被定义为一个单选特征组;

2) 如果f为可选特征,则f'被定义为可选特征并与f互斥;

3) 如果f为单选特征组成员,则f'插入到同一特征组;

4) 如果f为多选特征组成员,则f'插入到同一特征组并与f互斥.

· 当cr的类型为删除时,当且仅当f为必选特征时,其被修改为可选特征.

在该规则中,考虑到特征变更请求来自不同的定制产品,插入特征的配置约束默认定义为非必选特征.此外,对于修改类型的变更,如果f为可选特征或者多选特征组成员,则f与f'互斥.这样的设计可避免f和f'同时出现产品中.图7显示了一个定义和更新特征配置约束关系的 例子,该例源于图5(a)所示的特征变更.f_mrl,f_prl和f_rv分别为变更“我的风险列表”、“项目风险列表”和“风险视图”得到的特征.根据规则3,可将它们插入到变更前特征的邻居节点.由于3个变更前特征均为必选特征,更新配置约束关系后,其分别与f_mrl,f_prl和f_rv形成单选特征组.

3.1.3 特征扩展关联关系分析

除了定义和更新变更涉及特征的配置约束关系以外,还需对这些特征的前置、限制和相似关系的变化进行分析.其中,特征变更请求隐含的特征间前置、限制和相似关系的改变随特征插入在特征模型中直接定义.此外,由于修改类型变更中的变更后特征与变更前特征功能相似,可认为二者之间存在相似关系,如图7中的f_mrl和“我的风险列表”.类似的,一组相似特征变更后的特征之间也可存在相似关系,如图7中的f_mrl,f_prl和f_rv.因此,在定位过程中还需在模型中为这些特征建立相似关系.

3.2 共性提取和模型修剪

保持良好的共性和可变性设计,是FOSD高效复用的前提条件,也是特征模型演化分析的关键.由于不同产品提出的特征变更请求相异,定位这些变更的影响减少了模型中的必选特征,降低了产品共性.本节进一步分析变更涉及的特征,通过共性提取和模型修剪,挖掘更多的特征用于后续产品的复用开发.

3.2.1 候选特征筛选

在变更涉及的特征中,并不是所有特征都有可能被定义为产品共性.分析这些特征,可发现其中两类特征可作为共性分析的候选:定位时插入的可选特征和形成的相似特征.其中,定位时插入的可选特征可直接作为产品共性的来源.对于一组相似的特征,可利用这些特征之间的共性部分进行复用开发.这些相似的特征由两种方式构成:一种由定位添加类型变更插入的可选特征组成,另一种由定位修改类型变更中的变更前和变更后特征组成.实际上,一组相似特征变更后的特征之间也存在相似关系,例如图7中的f_mrl,f_prl和f_rv.但是这些特征的父特征不同,对其重构或者修剪,可能破坏特征模型的层次结构.因此,我们不考虑这些相似特征.上述两种类型的候选特征均可从定位阶段输出的模型演化操作集合中,根据操作名称和操作目标筛选得到.由于两类特征存在交叉,我们首先分析相似特征而后在可选特征中进行选择.

3.2.2 相似特征分析

相似特征的分析以特征的共性和可变性分析为基础,通过重构的方式挖掘其中共性部分,同时修剪特征模型.本文采用自然语言描述特征,因此,对特征进行共性和可变性分析需首先解析特征的内容.我们采用了Fillmore的“格语法(semantic grammar)”^[31]对特征内容进行语义解析,该方法曾应用于Niu和Guo等人的研究中,通过格语法中的“语义格(semantic case)”解析需求描述中的人、地点、频率等上下文信息,进而识别需求的共性和可变性^{[32, 33]}.我们也采用同样的方式解析特征.表5列出了本文解析特征时所用到的语义格.

根据特征语义格,可对每组相似特征的内容进行解析和对比,识别特征的共性和可变性.表6显示了两组相似特征组的解析结果.特征f₁,f₂和f₃均是在添加风险时设置风险值,它们的可变点(variation point)发生在temporal,即,风险值的范围不同;f₄和f₅通过不同的方式共享会议记录,其可变点发生在instrumental.

根据共性和可变性分析的结果,可对一组相似的特征进行重构.为保持重构前后的特征功能和配置约束,我们根据相似特征构成的方式定义了重构规则:

规则4. 对于一组相似的特征F={f₁,f₂,…,f_n},根据其共性和可变性分析结果,可将这些特征重构为一组父子特征.f_p为父特征,取自F的共性部分;为f_p的子特征,取自F中每个特征的可变部分.

· f_p的配置约束可按照如下规则定义:

1) 当F完全由可选特征构成时,将f_p定义为可选特征;

2) 当F由变更前和变更后特征构成时,f_p的配置约束与变更前特征一致.

· 对于子特征_{$\{ {f_{c{h_1}}},{f_{c{h_2}}},...,{f_{c{h_n}}}\} $}的配置约束,如果F之间存在互斥关系,将_{$\{ {f_{c{h_1}}},{f_{c{h_2}}},...,{f_{c{h_n}}}\} $}定义为f_p的一组

单选特征;否则,将这些特征定义为f_p的一组多选特征.

图8显示了对表6特征f₄和f₅重构的结果.

根据规则4,f₄和f₅重构为一组父子特征.父特征来自于二者的共性部分,即“共享会议记录”.子特征为共享的方式,可通过在线共享或者E-mail共享.由于f₄和f₅均为可选特征且非互斥,因此将“共享会议记录”定义为可选特征,两个子特征定义为一组多选特征.

3.2.3 可选特征分析

一个特征是否为可作为产品的共性,取决于多方面因素^[7].在选择前,分析人员应建立决策准则对每个特征进行评价.根据一些典型的决策影响因素,我们设计了规则,从定位插入的或者重构生成的可选特征中选取产品共性,并在模型中修改其配置约束关系.

规则5. 对于定位插入或者重构生成的可选特征f,当该特征满足以下一个或者多个条件时可定义为产品共性,并在特征模型中将其更新为必选特征:

· 请求f的产品数量占所有产品的比例超过预定阈值t₁;

· f符合行业标准的程度大于预定阈值t₂;

· f符合产品战略的程度大于预定阈值t₃.

由于特征变更的定义中包括请求特征的产品信息,因此请求特征的产品比例可以根据特征变更中的产品属性计算得到,其他两项因素则需要分析人员进一步收集数据.但是在应用规则前,应邀请领域专家确定各个影响因素的阈值.除了规则5列举的决策因素外,由于项目背景和环境不同,还可能存在其他决策因素,例如客户的优先级.本文不再对这些因素逐一列举.如果需要添加新的决策因素,可参照规则5的方式定义.

3.3 冲突消解

为了保证特征模型配置的一致性,本阶段进行配置冲突检测和消解.由于我们假设方法输入特征模型的配置是一致的,配置冲突只可由配置约束相关的特征模型变化引发^[9].由此,冲突检测可从前面两个阶段发生配置约束关系变化的特征出发,而不是遍历整个特征模型.

配置冲突的检测主要依据表2所描述的冲突类型.发现冲突后,一般可通过删除或者修改其中一种配置约束关系达到消解的目的.因此对于同一类型配置冲突,可有多种消解策略.根据不同的冲突类型,我们列举了几种典型的消解策略:

· 策略1:检查发生配置冲突的两个特征,移除依赖关系.该策略适用于消解Type Ⅰ,Type Ⅳ和Type Ⅴ类型的配置冲突.

· 策略2:检查发生配置冲突的两个特征,移除互斥关系.该策略适用于消解Type Ⅱ,Type Ⅲ和Type Ⅴ类型的配置冲突.

· 策略3:将发生配置冲突的完全必选特征改为非完全必选特征,即,将该特征或者其到根节点路径上的任意特征更改为非必选特征.该策略适用于消解Type I,Type Ⅱ和Type Ⅲ类型的配置冲突.

· 策略4:检查发生配置冲突的两个特征,消除特征之间单选约束.该策略适用于消解Type Ⅳ类型的配置冲突.

在检测过程中,一旦发现配置冲突,分析人员就需要根据冲突类型选择合适的消解策略.改变特征配置约束关系后,应仔细检查特征的功能和行为,保证特征间正确的关联关系.由于执行消解策略可再次引入新的配置约束关系变化,因此冲突消解完成后,还需根据消解冲突引发的配置约束关系变化继续检测,直到不存在任何配置冲突为止.

可选特征“JBCM”是在定位阶段插入的可选特征,该特征描述了系统采用一个第三方的工具和方案管理配置库,而非系统内置的配置管理功能.它与系统原有特征“管理配置库”互斥.由于“管理配置库”为一个完全必选特征,因此,“JBCM”与“管理配置库”间被检测出Type II冲突.消解该冲突可采用策略2或者策略3.分析人员选择了策略3,将“管理配置库”改变为可选特征.

冲突消解后,即完成了特征模型的演化分析过程,输出结果为模型的演化操作集合,根据该集合对输入的特征模型操作,可得到演化后的特征模型.项目分析人员和开发人员可根据该特征模型进行后续的重用开发活动.

4 案例分析及验证

为了验证本文提出方法的可用性和有效性,我们建立了半自动化分析工具FMEVO-Tool(工具的具体实现可参考http://itechs.iscas.ac.cn/cn/membersHomepage/hujie/FMEvolutionAnalysis.rar).通过该工具,在一个实际的软件系统上进行案例分析.由于本文重点在介绍方法,本节只描述案例分析的过程和结果.

案例分析对象来自于一个软件过程管理系统Qone,该系统与Microsoft Project系统相似,主要为组织或者机构内部的软件过程管理提供协作平台.Qone系统的主要功能包括软件项目管理和过程管理等,例如项目计划、项目监控和软件度量.截至目前,该系统已经应用于超过200个组织和机构.由于客户所采用的软件过程管理方式存在差异,项目组通过定制开发的方式满足客户对系统的特定要求.在定制化开发过程中,特征模型用于对系统的共性和可变性建模,支持复用开发和系统配置.随着近年来客户数量的不断增长和用户需求的快速变化,该系统特征模型的演化更加频繁.

4.1 收集数据

我们通过Qone项目组收集了系统的特征模型,并根据第2.1节的扩展,补充特征间的前置、限制和相似关系.当前,该模型共包含579个特征.产品共性主要体现在项目管理、过程管理等软件过程管理常规功能,可变性则分布于项目数据、系统设置等功能.这些特征可根据客户环境进行选择和设定.图1所示的特征模型片段即来自该系统.项目组还提供了来自7个定制产品的106个特征变更请求,去重后得到95个变更请求.表7按照产品和变更类型显示了这些特征变更请求的统计.

4.2 定位特征变更的影响

利用规则1和规则2,我们在特征模型中分析了95个特征变更造成的“涟漪”效应.18个特征变更被识别并经过分析人员确认,表8显示这些特征变更的信息.它们以修改类型为主,多数是根据修改类型的特征变更,利用相似关系识别.图5显示了其中的两个变更.

识别“涟漪”效应引发的特征变更后,共有113个特征变更需要进一步分析.利用规则3,可对变更涉及特征的配置约束关系进行定义和更新.分析结果如下所示:

· 对于41个添加类型的特征变更,31个请求添加的特征插入为可选特征,其余10个特征分别插入到2个单选特征组和8个多选特征组中.

· 对于67个修改类型的特征变更请求,54个必选特征和其64个变更后特征组成了单选特征组,3个变更后特征插入到变更前特征所在的多选特征组中,并与变更前特征互斥.

· 对于5个删除类型的特征变更请求,只有一个特征的配置约束关系被改变,即,将“定时任务”从必选特征改为可选特征.

特征变更隐含的扩展关联关系变化随插入操作在特征模型中定义.而后,对插入的特征进行相似关系的分析,共发现126个相似特征.

4.3 提取共性和修剪特征模型

在变更涉及的特征中筛选候选特征,得到31个可选特征和126个相似特征.在分析相似特征时,我们根据表5所示的语义格解析这些特征.通过对比每组相似特征的语义格后,得到这些特征的共性和可变性,进而根据规则4在特征模型中重构这些特征.分析结果如下所示:

· 对124个变更前特征和变更后特征组成的相似特征组重构,可得到57个父特征和124个子特征,其中,54个父特征被定义为必选特征,3个父特征仍然在原有的多选特征组中.124个子特征分别定义为单选特征组.

· 对两个可选特征组成的相似特征组重构,可得到一个父特征和2个子特征.父特征被定义为可选特征.由于重构前特征间不存在互斥关系,因此两个子特征被定义为一个多选特征组.图8中的例子即源自于这两个特征.

重构相似特征后,共有30个可选特征提交给分析人员.Qone项目组主要通过请求特征的客户比例和特征是否符合行业标准作为共性决策依据.根据这两项因素的阈值对特征进行选择,只有一个特征“维护项目资产库”满足规则.该特征与行业的软件过程管理标准相一致.

为了验证本阶段分析的有效性,我们选取了共性比例(commonality ratio,简称CRatio)作为评价指标.CRatio表示被定义为产品共性的特征的百分比,可通过模型中必选特征数量与所有特征数量相比得到.产品共性发生改变时,CRatio也随之变化.因此,可以通过对比分析前后的CRatio显示分析方法是否可以挖掘出潜在的共性. CRatio越高,越有利于复用开发.

表9显示了前一阶段和本阶段分析完成后CRatio的统计结果.特征变更定位阶段向模型插入的特征均为非必选特征,同时,将模型中原有的必选特征修改为非必选特征.本阶段则对定位插入的可选特征和形成的相似特征进一步分析,提高了模型中的必选特征数量.特征模型中的特征总数也随相似特征的重构而上升.对比两个阶段,可观察到CRatio提升了4.1%,验证了本阶段对潜在共性挖掘的有效性.

通过上述的分析可以发现,在演化过程中是否能够提取出共性,主要取决于两个条件:一是是否可从变更涉及的特征中发现候选特征,二是这些特征是否符合共性分析和决策规则.如果存在符合条件的特征,按照本文描述的分析过程即可发现其中潜在的共性.

4.4 消解冲突

在发生配置约束关系变化的特征之间检测配置冲突,只有一个Type Ⅱ类型的冲突被发现并被消解.图9所示例子即来源于此.

我们利用两个现有的工具FeatureIDE^[34]和RequiLine^[35]验证冲突消解的效果,这两个工具都可以对特征模型进行图形化编辑,检查模型是否存在配置冲突.我们分别将冲突消解前后的特征模型输入到工具中.图10显示了在FeatureIDE中消解冲突前后的特征模型片段.在冲突消解前,可选特征“JBCM”的插入导致其与一个完全必选特征“管理配置库”互斥.在图10(a)中,FeatureIDE识别出该冲突.经过冲突消解后,图10(b)显示,该冲突已被移除.最后对特征模型所有特征的配置约束关系检查,不存在配置约束冲突.

4.5 扩展效果分析

演化分析完成后,我们统计了每个分析阶段特征模型的变化,进一步分析扩展特征关联关系对演化分析的影响和效果.表10显示了每个分析阶段后特征模型中每种关联关系相关特征的数量,多数的变化都发生在前两个阶段,尤其是必选、可选、单选和相似关系特征的数量.由于输入的特征变更多以添加和删除类型为主,定位这些变更增加了可选、单选和相似特征,同时削减了的输入模型中的必选特征.而在共性提取和模型修剪中,对相似特征的重构增加必选特征的数量,并消除了这些特征间的相似性,减低了相似特征的数量.

为了验证模型扩展对演化分析的影响和效果,我们分别在扩展特征关联关系前后的特征模型基础上运行分析方法,并统计了所有分析阶段取得的配置约束关系相关的演化操作,如图11所示.对比两种场景可观察到:在多数演化操作类型上,扩展后分析取得的操作数量都大于扩展前.尤其在InsMan,InsAlt,DelAlt和MovToAlt数量上,前者显著大于后者.二者之间的差距主要由于扩展特征关联关系增强了“涟漪”效应的分析,从而发现了17个修改类型的特征变更.定位这些特征变更,使得更多的特征被插入到或者移动到单选特征组中.这些操作也为共性提取提供了更多候选特征,使得更多的特征被重构,提高了必选特征的数量.

上述分析结果表明了扩展特征关联关系对演化分析的影响,同时也验证了扩展对于演化分析的必要性.即,在扩展基础上分析特征模型演化,可得到更为全面的演化操作.

5 讨 论

尽管案例分析验证了方法的可用性和有效性,但是该方法在某些方面仍然存在局限性.此外,在案例分析过程中,通过和项目人员的讨论,我们也得到一些经验.

5.1 方法的局限性

方法的局限性主要体现在3个方面:扩展特征关联关系、“涟漪”效应分析和冲突消解策略.

(1) 扩展特征关联关系与特征配置约束关系的相关性

对比配置约束关系和扩展关联关系,可以发现依赖与前置或者限制之间可存在一定的相关性.对于具有前置或者限制关系的特征,其可能在配置上也存在依赖关系.例如在图3(a)中,完全必选特征“设置数据库”前置于可选特征“备份数据”,“备份数据”也依赖于“设置数据库”.而在一些研究^{[9, 34]}中,若可选特征依赖于完全必选特征,则该依赖关系被视为冗余,需在特征模型中消除.因此,图3(a)中并没有显示二者间的依赖关系.但是,如果在“涟漪”效应分析只采用依赖关系,某些特征变更将无法被发现.例如,修改“设置数据库”增加系统支持的数据库类型,可引起“备份数据”的变 更,如果不补充前置关系,则无法识别该类变更传播.因此,补充前置和限制关系对于“涟漪”效应分析是必要的.

(2) “涟漪”效应分析

由于特征是系统的高层抽象,其变更带来的“涟漪”效应具有不确定性^{[6, 29, 30]}.虽然我们设计了规则发现可能受影响的特征和特征变更的类型,但是为了提高分析的准确性,我们建议在利用规则分析后,将分析结果提交给分析人员,通过人工检查的方式保证结果的准确性.

此外,在分析“涟漪”效应时,我们只考虑从扩展的3种关联关系出发.实际上,父子特征之间也可能存在变更的传播.由于特征模型的树形结构,父子特征间的变更相比扩展关联关系上的变更传播更为复杂.修改模型高层的特征,可能导致其所有后继特征发生变化.本文中不考虑父子之间的变更传播,如有父特征变更影响子特征的场景,需在输入中逐一为受影响的子特征定义特征变更请求.

(3) 冲突消解策略

我们根据不同的配置冲突类型设计了消解策略,除了这些策略以外,还可能存在其他的选择,例如,将Type I中的非完全必选特征更新为完全必选特征.这样的操作虽然解决了配置冲突,但是该特征并不是所有产品都需要的,违背其实际的配置要求.因此,我们并未将类似的策略纳入方法中.

在消解配置冲突时,我们为分析人员提供了多种消解策略.最终选择哪一种策略,则需要分析人员根据实际情况做出决策.由于执行不同消解策略花费的工作量不同,对系统和定制产品造成的影响也不尽相同.因此,分析人员可通过收集影响因素建立统一的评价方法,对每一种消解策略进行影响分析,从而选择合适的策略消解冲突.

5.2 案例分析经验

进行案例分析后,我们与Qone项目组探讨方法的使用和应用结果时,得到一些意见和建议.综合这些意见和建议,我们得到如下几点经验:

(1) 特征重构的价值分析

解析和重构相似特征是共性提取和模型修剪的重要步骤,在案例分析中,约有126个特征需要进行解析和重构.由于执行这些分析需要花费一定的工作量,对于定制规模较小的软件而言,重构虽然提升了复用,但是重构带来的开销可能高于收益.对于一些需要快速交付的产品,先重构后开发的方式也可能延迟交付时间.因此,在进行特征解析和重构时需要进行价值分析,平衡解析和重构的开销和收益.

(2) 在分析前对特征变更聚类

由于领域内包含众多的定制产品,可能出现对同一特征不同语义格的变更请求或者同一语义格的不同请求.针对此类变更请求,项目人员建议我们在演化分析前对变更进行聚类,从而提高分析的效率.

6 相关工作

本文的相关工作主要涉及两个方面:特征关联关系的扩展和特征模型的演化分析.

(1) 特征关联关系的扩展

特征模型最早由Kang在1998年提出^[3],作为面向特征的领域分析(feature oriented domain analysis)方法的核心.由于特征建模具有简单、灵活、易理解等优势,使其一经提出就吸引了众多的研究人员,并逐步成为重要的共性和可变性建模方法之一.此后,很多研究在该模型的基础上进行扩展,以满足不同的应用场景.综合特征模型分析的系统化调研^[18]和特征模型扩展工作的总结^{[2, 36]},可将扩展归纳为3个方面:特征的属性、特征的基数和特征的关联关系.

本文所提出的扩展从属于特征关联关系方面,因此,本节主要总结该方面的研究,并进行对比.

特征关联关系的扩展工作中,Lee等人根据特征模型在设计可适应(adaptable)和可配置(configurable)资产时存在的缺陷,从特征操作的角度引入了多种关联关系^[19].补充的特征关联关系包括使用(usage)、修改(modification)和激活(activation).Zhang等人面向特征分析了需求间的关联关系,增加了静态和动态特征关联关系^[20].其中,静态关联关系包括精化(refinement)和限制(constraint),动态特征关联关系主要为影响(influence)和交互(interaction).Peng等人对特征模型进行了更严格地定义,给出了3种特征关联关系:使用(usage)、决定(decide)和配置依赖(configdepend)^[21].通过这3种关联关系,更为细致地描述运行时和绑定时(binding)特征间的交互性及配置约束.

上述研究工作进一步增强了特征模型对特征相关性的表达能力,然而对于“涟漪”效应分析而言,关键是识别不同层次和类型关联关系上的特征变更传播.这些扩展只是对特征在配置和重用上相关性的进一步刻画,并没有从其他角度进行补充.将这些扩展得到关联关系与已有变更传播研究^[24]对比可发现,采用这些扩展的特征模型仍然不足以支撑“涟漪”效应的分析.与这些研究不同,本文所提出的扩展主要面向特征变更的“涟漪”效应,分析特征间不同抽象层次或者不同方面的关联关系,从中选择可用于“涟漪”效应的关联关系类型补充到特征模型中,实现了在特征模型基础上分析特征变更“涟漪”效应.此外,扩展的关联关系还可用于识别潜在的产品共性,为共性提取和模型修剪提供更多的候选特征.

(2) 特征模型的演化分析

特征模型演化分析的研究主要包括演化影响分析、重构和模型诊断等多个方面.

在演化影响分析方面:Riebisch主要以特征模型为桥梁建立需求与其他软件制品的跟踪关系,通过需求的变更分析演化对特征模型以及其他制品造成的影响^[11];Peng等人分析了影响特征模型演化的因素,识别可能发生的模型变化和受影响的特征,并对模型变化进行价值分析和排序^[12].这些方法主要从需求工程的角度分析特征模型演化.

其他方面,Botterweck等人归纳了特征模型演化的元操作集合EvoOperators^[25];Hwan等人提出多种特征模型的操作,例如删除节点、删除子树^[26];Thum等人引入了重构、归纳(generalization)、特化(specialization)和随意性编辑(arbitrary edit)描述演化前后特征模型的变化^[37];Alves等人基于特征模型提出了产品线重构模式^[38].还有许多研究人员采用SAT(satisfiability solving),BDD(binary decision diagram)和CSP(constraint satisfaction problem)对模型的有效性进行诊断^{[15, 16, 39]}.Guo等人提出在演化时通过设定策略修复不一致的特征模型配置^[10].

上述研究中,其中一部分以需求规约或者需求模型分析特征模型的演化.这些研究只是在需求层面上进行演化分析,通过特征模型表达共性和可变性的变化,并非是从特征模型本身的角度考虑演化.由于需求模型缺乏对特征和特征关联关系的描述,分析过程中可能忽略特征变更的“涟漪”效应,无法发现由此引发的共性和可变性变化.与这些工作不同的是,本文通过扩展特征关联关系实现了在特征模型基础上进行特征变更的“涟漪”效应分析,并通过共性提取和模型修剪发现更多的产品共性.此外,本文提出的方法还考虑了模型配置冲突的发现和消解.与上述研究中的模型诊断的研究相比,本文仅从发生配置约束变化的特征出发检测配置冲突.与Guo等人的研究类似,本文同样假设输入的特征模型不存在任何异常,配置冲突只可由模型演化操作引发,并不需要遍历整个特征模型进行检测.但是对于冲突消解,上述工作并未说明如何消解不同类型的配置冲突,Guo等人的研究也仅描述如何修复删除特征造成的配置异常.本文则定义了详细的策略应对每一种配置冲突.

由于识别共性和可变性的变化是特征模型演化分析重要组成,因此我们在研究过程中也参考了共性和可变性分析的相关工作.分析相似特征时,采用Guo等人分析功能性需求的方法^[33],通过“格语法”对特征进行语义分解.在对可选特征进行共性分析时,我们总结了相关工作中分析产品共性的决策因素^{[7, 17, 33, 40]},在这些因素基础上设计了规则辅助开发人员决策.

7 总 结

本文在分析当前特征模型演化分析的挑战和现有方法存在的问题基础上,提出了一种软件特征模型演化分析方法.该方法扩展了特征关联关系和模型演化元操作,通过这些扩展,支持在特征模型基础上分析和识别特征变更的“涟漪”效应引发的特征变更,发现和提取潜在的产品共性.同时,该方法还对演化过程中出现的配置冲突进行消解.为了验证该方法的可用性和有效性,实现了半自动化的分析工具,并选取了一个具有代表性的软件系统Qone进行案例分析.分析结果表明,我们所提出的方法可以用于实际的项目并辅助项目人员进行特征模型演化分析.

在研究过程中,我们也发现了该方法存在的不足,并在案例分析中收获了一些经验教训.这些都为我们指明了下一步的研究方向,包括:对特征变更进行聚类分析,提高方法的效率;对特征解析和重构进行价值分析;建立冲突消解策略选择方法;评价特征模型演化对软件开发的影响.此外,我们也将持续关注Qone项目,并计划采用更多的方式验证方法的有效性.同时,也希望在更多的软件系统和业务场景中进行应用,不断改进方法.