软件产品线模型的演变分析与管理

制作和主办：ElsevierJournalof King Saud University沙特国王大学沙特国王大学学报www.ksu.edu.sawww.sciencedirect.com软件产品线Jihen Maa Bazouna，*，Nadia Bouassidaa，Hane Bazoune Ben-Abdallahba突尼斯斯法克斯大学MIR@CL实验室b沙特阿拉伯吉达阿卜杜勒阿齐兹大学接收日期2015年6月5日;修订日期2016年1月9日;接受日期2016年1月13日2016年3月30日在线发布摘要软件产品线（SPL）代表了特定应用领域中的一系列产品。每个SPL的构建是为了通过覆盖其领域中的广泛功能来然而，随着时间的推移，一些领域的特征可能会变得明显，随着新特征的出现而消失，而其他特征可能会变得精致。因此，必须维护SPL以说明域的演变。这种演变需要一种方法来管理SPL模型（包括特征模型和设计）上的变化的影响。本文提出了一种自动化的方法，分析特征模型的演变，跟踪其对SPL设计的影响，并提供了一组建议，以确保这两个模型的一致性。所提出的方法定义了一组适应SPL演变的新指标，以确定保持SPL模型一致性所需的工作量，并且质量与原始模型一样好。通过一个文本编辑领域的SPL实例说明了该方法及其工具。此外，还对它们的维护质量和维护成本进行了实验评估。SPL模型的精确性和影响变化的管理。©2016作者。制作和主办由爱思唯尔B.V.代表沙特国王大学。这是CC BY-NC-ND许可下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。内容1.导言. 3652.相关工作3662.1.SPL建模3662.1.1.特征模型3662.1.2.我们的软件产品线UML概要367*通讯作者。电子邮件地址：jihenmaazou n@www.example.comgmail.com（J. 我也是娜迪亚。Bouassida@ isimsf.rnu.tn（N. Bouassida），HBenA bdallah@ka uedu.sa。Ben-Abdallah）。沙特国王大学负责同行审查http://dx.doi.org/10.1016/j.jksuci.2016.01.0051319-1578© 2016作者制作和主办由爱思唯尔B.V.代表沙特国王大学。 这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。关键词软件产品线;特征模型;模型演变;变革影响管理软件产品线的变更影响分析3652.2.SPL进化水平和操作3672.2.1.特征模型重构3672.2.2.特征模型细化3682.2.3.特征模型任意演化3682.3.关于SPL变化影响分析的现有工作3682.4.其他SPL演变问题3683.衡量SPL演进变化所需的工作量3694.特征模型和设计级变更影响分析3704.1.特征间模型更改3704.1.1.添加功能3704.1.2.删除特征3704.1.3.装饰特征3714.1.4.移动特征3714.1.5.分离特征3714.2.内部特征模型更改3714.2.1.添加元素3724.2.2.移除元件3724.2.3.372号元素4.3.影响分类3725.案例研究3736.评价3746.1.进化后SPL质量评估3756.2.变更影响评估3777.结论378参考文献3791. 介绍软件产品线（SPL）（Clements and Northrop，2001）代表了一组软件密集型系统，这些系统共享与特定应用领域相关的一组常见功能和软件资产。除了常见的产品功能外，SPL还描述了可用于在SPL域中导出新产品的可变点。由于其功能和软件资产的预测性和有组织的重用，SPL承诺缩短上市时间并提高软件开发效率。尽管SPL涵盖了几个软件变体，但后者的不可避免的演变导致了SPL本身的演变。产品变体不断发展，以满足新技术、新业务目标或客户偏好变化带来的新需求。这样的产品变体的演变反馈关于它们的SPL的几种类型的变化，例如，新特征的出现、过时特征的消失、特征的结构重组等。管理产品变体的演变对SPL的影响SPL通常根据问题空间和解空间来描述（Seidl等人，2012年）。问题空间通常以特征模型的形式捕获高级需求，而解决方案空间包含共享资产，如源代码、设计和测试工件。考虑到两个空间之间的紧密联系，必须在所有相关资产中以一致的方式管理SPL演变引起的任何变更。大多数涉及SPL进化的作品，例如，Pleuss等人（2012）、Passos等人（2013 ）、Seidl 等人（2012 ）、 Neves 等人（2011）、Laguna和Crespo（2013）以及Xue（2011），关注面向特征模型SPL，但它们没有解决变更对SPL的各种资产的一致性的影响，例如，设计和产品代码。此外，现有的工作中没有一个分析的成本变化的估计的努力来处理的变化;这种变化的影响分析是重要的，例如，检查的价值增加了变化。因为特征比需求更结构化和粗粒度，所以它们促进SPL演化的理解和可跟踪性（Passos等人，2013年）。事实上，Passoset al.（2013）认为应该以面向功能的方式管理更改。我们同意这一观点，因为我们相信功能可以是蓝图，在那里可以管理进化，并从那里可以追溯到设计，代码和其他资产。因此，管理SPL演变意味着，首先，在问题空间级别管理变化（即，特征模型），然后，跟踪这些变化到解空间（即，设计）。为了实现这种面向特征的SPL演化策略，必须解决两个问题：如何保持特征模型与剩余资产，特别是设计之间的一致性？以及如何衡量在管理每个变更影响时所需的工作量要解决这两个问题，需要明确说明SPL特征模型及其设计之间的关系。为此，我们使用我们精心提出的方法，该方法从源代码中提取特征模型，并使用UML概要文件对其进行指定（Maazoun等人， 2013年）。与现有SPL特征模型提 取 方 法 （ 例 如 ， Acher et al. （ 2013 ） ， Lozano（ 2011 ） ， Ziadi et al. （ 2012 ） ， Al-Msie 'Deen et al.（2012）和Paskevicius et al.（2012）），我们的集成了产品变体的语义方面。此外，它还使用UML概要文件描述了SPL设计，该概要文件表示SPL变化点，这些变化点富含从特征模型中提取的信息。这种丰富提供了特征模型和设计之间的可追溯性。366J. MaaRizzoun等人除了特征模型和设计之间的显式关系外，SPL演化管理还需要一种方法来识别每个更改操作的影响。为了满足这一要求，我们首先指定了在添加、移除、拆分、重命名或移动特征或属于特征的元素时，特征模型中可能发生的不同更改。其次，我们定义了一组规则，这些规则将每个更改的影响形式化，同时保持设计图和特征模型的一致性，并保持更改后的特征模型和SPL设计之间的可追溯性。此外，为了保持更改后的SPL特征模型和设计之间的可追溯性，我们采用了一组语义标准，以表达受影响元素名称之间的语言关系。语义关系是从WordNet词典（Ben-Abdallah等人，2004），如果它们存在，或者通过测量特征值得注意的是，如Botterweck和Pleuss（2014）所述，SPL演进在文献中从不同的角度进行了研究：SPL演进历史的分析、未来SPL演进的规划以及SPL演进的实现。所有这些观点都有两个共同的先决条件：明确说明演变变化，以及准确识别其影响。本文介绍的工作有助于满足这两个先决条件，以便管理（分析和实施）SPL级别的更改，即，SPL特征模型及其设计。此外，与现有的SPL演化管理方法相比，我们的方法具有以下优点：它管理的变化对功能模型和设计资产的影响;它保持这两个资产之间的可追溯性和一致性;它使用一组定量的软件度量，以帮助评估管理变更所需的努力，评估可以用来决定是否接受变更请求或拒绝它;它是高度自动化的，通过一个工具支持，名为Evo-SPL，管理软件产品线的系统演化。除了自动识别受变更影响的所有元素外，Evo-SPL还生成一份报告，其中包含确保设计图和特征模型之间的一致性所需的额外变更数量。设计人员可以使用此报告来决定应该重新考虑和/或取消哪些更改。一旦他们决定接受更改，Evo-SPL会自动转换设计和特征模型，使它们保持一致。本文的其余部分组织如下：第2节概述了特征模型的概念和与SPL演化策略和变更影响分析相关的现有工作，并描述了我们的UML概要文件适用于SPL的原型，标记值。第3节提出了一套衡量管理变更影响所需努力的标准。第4节介绍了演化的一致性和所涉及的风险;此外，它还介绍了不同的特征模型间和特征模型内的变化，它们的影响和不同的一致性规则。第5节给出了一个游戏应用程序领域的SPL的案例研究，并通过我们的EVO-SPL工具对其进行了演化管理。第6节评价演变后SPL质量和变更影响。最后，第7节总结了所提出的工作，并概述了其扩展。图1特征模型的示例。2. 相关工作在这一节中，我们首先回顾一下特性模型的概念和我们用来指定软件产品线的UML概要。其次，为了界定本文所述工作的范围，我们在第2.2节中强调了SPL演变的主要原因以及处理它们的现有操作。在第2.3节中，我们概述了处理SPL变更影响分析的工作。最后，在第2.4节分析中，我们简要讨论了与变更影响分析紧密相关的三个主要问题，主要是演化一致性、风险评估和工作量估计。2.1. SPL建模如在引言中所提到的，SPL通常根据问题空间和解空间来描述（Seidl等人，2012年）。问题空间通常以特征模型的形式捕获高级需求。解决方案空间包含共享资产，如源代码、设计和测试工件;在本文中，我们认为解决方案空间是通过我们的UML概要建模的设计（Maazoun等人， 2014年）。2.1.1. 特征模型特征模型是一种在抽象层次上表达领域需求的常用方法。它们用于描述产品线中产品的可变和共同属性，并用于推导和验证软件系统的配置。如由FODA方法（Kang等人，1990）和Czarnecki和Eisenecker（2000 a），特征模型表示领域概念属性的层次结构。功能是软件系统的突出或独特的质量或特性（Kang等人，1990年）。它是一个概念的“可区分特征”（例如，组件、系统等）这与概念的某些利益攸关方有关功能模型允许设计人员在具体代码和文档的抽象信息（如架构和设计）之间架起桥梁。每个要素模型都具有树结构，其中每个节点表示一个要素●●●●●●●软件产品线的变更影响分析367(see图1）。特征可变性由特征的弧和分组表示。有两种不同类型的功能组：强制性：（子）功能，必须存在于每一个产品线。可选：某些产品中可能存在的（子）功能。除了特征之间的父关系之外，树结构中的节点之间的约束用于约束从SPL导出产品。五种最常见的交叉树约束是：并且：在从SPL导出产品的过程中，异或：在从SPL导出产品或者：在从SPL导出产品的过程中，可以选择一个或多个（子）特征。要求：选择一个（子）特征需要选择另一个。注意：两个（子）功能不能是同一产品的一部分。图1示出了描述汽车SLP的数字特征模型的示例，其中一些特征是强制性的（“变速箱”功能可以是手动或自动的，而“发动机”可以是专门的“汽油”或“电动”。此外，这个SPL的例子说明，如果一辆汽车有一个SPL被重用以在SPL域中派生具体产品。具体产品首先由产品配置定义，产品配置通过选择或消除特征模型中的特征来解决可变性（Botterweck和Pleuss，2014），同时尊重模型的约束。然后基于SPL提供的资产进行开发。为此，必须链接特征模型元素及其资源。2.1.2. 我们的软件产品线为了确保SPL特征模型和它的设计之间的可追溯性，我们建议使用我们为SPL定义的称为SPL-UML（Maazoun等人，2014年）。SPL设计通过UML设计图（包、类、序列等）在SPL-UML中建模。其通过一组被引入以对软件产品线的可变性方面进行建模的原型来扩展。由于篇幅限制，我们接下来简要回顾一下类图中引入的七个原型：optional用于指定UML类图中的可选性。可选性可以与类、包、属性或操作相关联。recommended 用 于 在 UML 类 图 中 指 定 推 荐 。recommendation构造型只适用于类。mandatory用于指定强制性要素。它可以与类、包、属性或操作相关联。mandatory_association用于指定UML类图中类之间的强制关系。它用一条粗线表示。optional_association用于指定UML类图中类之间关系的可选性。它用虚线表示。Xor_association用于指定UML类图中类之间Feature_Name用于指定元素所属的功能的名称。它与类、包、属性和操作相关。它是SPL设计和其特征模型之间的可追溯性的一种手段。我们注意到，在设计方面，一个特性可以是简单的/基本的，只包含一个设计元素，如{package}和{class}，或者由几个设计元素组成，如{package，class}，{package，class，attribute，method}等。2.2. SPL演进级别和操作鉴于其开发成本高昂，SPL的寿命较长，因此将不断发展以满足其领域的新需求和修改需求。与单一系统相比，SPL演化具有更高的复杂性，这是由于问题空间模型和解空间模型之间的相关性以及生产线上产品之间的相互依赖性。正如Botterweck和Pleuss（2014）提出的SPL演变过程框架中所讨论的那样，SPL演变可以由业务目标和演变的外部触发因素（例如，市场变化）、产品衍生导致的不匹配和建议变更，以及产品或SPL的经验。此外，根据变更触发因素，Botterweck和Pleuss（2014）的框架将SPL变更分类为产品线级别和/或产品级别。为了处理这些级别上的SPL演化变化，有几项工作通过四种策略处理了SPL演化，即通过特征模型变化：重构、细 化 、 专 门 化 或 由 需 求 变 化 引 起 的 任 意 和 一 般 演 化（Thuém等人，2009年）。2.2.1. 特征模型重构重构重构特征模型，同时保留相同的元素集。这意味着没有添加或删除任何元素。这是许多研究人员的重点，例如，Alves等人（2006）、Loesch和Ploedereder（2007）、Mende等人（2008）和Schulze等人（2012）。例如，Alveset al. （ 2006 ） 定 义 了 一 组 重 构 操 作 ， 例 如 将 “alter-native“约束转换为”or”;这些特征模型重构操作重构SPL以改进它，同时保留其产品的行为。Mende等人（2008）支持通过复制和粘贴创建的产品变体的重构，这些变体可以传播到SPL级别。Schulze等人（2012）提出了变体保留SPL重构，以确保重构后所有SPL变体的有效性。重构的目标是在面向特征编程的环境中，在解决方案空间中重构SPL的代码●●●●●●●368J. MaaRizzoun等人2.2.2. 特征模型精化精化保留了乘积集（没有元素被删除），同时添加了新的特征或删除了一些约束。因此，所得到的特征模型是原始特征模型的泛化，例如，Borba等人（2010）和Neves等人（2011）（2011年）。Borba等人（2010）提出的SPL细化方 法 没 有 为 演 化 变 化 提 供 具 体 的 操 作 。 Neves 等 人（2011）提出了这项工作的改进，他们提出了安全产品线演变的模板。但是，模板中描述的步骤是手动执行的。此外，这项工作不考虑向SPL添加全新的功能2.2.3. 特征模型任意演化在任意进化的角度来看，Schubanz等。（2013）和Pleuss等人（2012）提出了EvoPl，这是一种计划和管理产品线长期演变的方法。EvoPl允许根据特征模型级别的更改来指定历史和计划的未来演进。EvoPl的优点是通过使用模型片段来聚类相关元素来降低复杂性。片段之间的关系用一个类似于名为EvoFM的特征模型的Romero等人（2013）提出了SPLEMMA，这是一种用于控制SPL进化的通用框架。SPLEMMA允许通过采用模型驱动的工程方法来验证受控SPL演化。它的优点是捕获SPL的演变，而不依赖于用于产品派生的资产、技术或特征模型的种类。授权的变更由SPL维护人员描述，并在用于生成工具的模型中捕获，这些工具用于指导演进过程并保持整个SPL的一致性。同样采用模型驱动的方法，Seidlet al.（2012）提出了一种模型驱动的产品线演化规划和监控方法。这种方法处理时间和空间维度上的进化。在时间维度上，它对时间概念进行建模，以支持长期持续的进化规划。在空间维度内，它支持从高层决策到实现的跟踪演变。这种方法有两个主要的局限性：它没有考虑到功能之间的约束，以及演化变化的影响只处理在可追溯性上。例如，当处理特性的移除时，影响仅在于移除可追溯性映射，而不移除与该特性相对应的代码和设计。因此，SPL代码资产最终包含大量代码行，不会用于衍生产品。最后，我们注意到，现有的工作SPL进化需要模型或检测模型之间的差异这是通过模型比较或增量模型（例如， Haber等人（2012）和Schaefer（2010））。模型比较，其中使用模型差分算法（例如，Xue（2011）），旨在比较模型或执行代码之间的差异EMFCompare1）识别特征发生的变化换句话说，这些工作假设已经发生了进化性的变化（在SPL级别或产品级别），并且他们需要识别它们。本文所介绍的工作补充了那些确定1基础。EMF：Eclipse建模框架2.0。网址http://www.eclipse.org/modeling/emf/。产品级别，并需要将它们传播到整个SPL。此外，它还支持那些需要在SPL级别分析需求变更的影响的工作，以实现风险评估、成本/工作量分析、实现等目的。2.3. 关于SPL变化影响分析的SPL上的更改会影响SPL模型（特征模型和资源），但只有在产品重新派生时，它们才会影响现有产品，例如发布包含SPL级别上所做更改的新版本产品。变更影响分析用于识别SPL模型所产生的变更，以及（如需要）必须重新衍生/重新配置的现有产品。它可用于规划SPL在其工程期间的未来发展和/或处理SPL级或产品级触发的为了说明SPL演变分析、规划和/或实施目的变更的影响，需要各种SPL模型之间的可追溯性。可追溯性将功能映射到SPL设计和实现元素，以实现面向功能的产品派生和SPL演进。在对可追溯性感兴趣的作品中，Passos et al.（2013），设想了一个面向功能的项目管理和系统开发，支持可追溯性，面向功能的实现工件分析，以及面向功能的特定推荐系统。Shen et al.（2009）提出了一个面向SPL开发的全面的可追溯性模型，该模型为各种功能类型提供了机制。该框架通过目标模型、特征模型、特征实现模型和程序实现四个层次为SPL开发提供了可视化的、全面的可追溯性表示。鉴于我们的工作范围较窄（SPL变更影响管理），我们使用UML概要文件（参见第2.1.2节），它以一种简单而全面的方式显式地链接设计和特征模型信息。SPL特征模型及其资产之间的可追溯性信息是SPL变更影响分析的基石。在本文的范围内，我们考虑了变更影响分析，该分析在特征模型级别和相关资产上识别受每个变更影响的所有元素。换句话说，我们不处理来自SPL的产品配置的变更影响分析。在这种情况下，很少有工作研究SPL的SPL模型的演变变化的影响。例如，在Heider et al.（2012），可变性变化影响分析可以通过自动化工具使用模型回归测试来自动化。此工具可告知工程师可变性模型变更对现有产品的影响，并重新推导所有产品，将其与之前的版本进行比较，并报告差异。此外，为了支持进化，Cordy等人（2012）提出了一种模型检查方法。然后，他们提出了一种方法来识别特定类型的特征，并表明对于这些特征，当添加到不断发展的SPL时，只有一部分产品需要再次进行模型检查2.4. 其他SPL演变问题除了可追溯性之外，SPL演进还必须解决以下与变更影响分析密切相关的问题：软件产品线的变更影响分析369所采用的演变的一致性、模型演变中的努力估计以及模型演变中涉及的风险（Michalik和Weyns，2011年）。这些问题中的每一个都可以只在改进的SPL模型（特征模型和资产）中处理，或者也可以在重建衍生产品中处理。如前一节所述，我们的工作范围仅限于SPL模型中的变更影响管理;因此，我们将把对这些问题的讨论限制在SPL模型中。通过演化一致性，我们的意思是演化的SPL模型在内部（特征模型和每个资产分开）是相互一致的（所有模型相对于彼此）。在这种情况下，Guo和Wang（2010）从原子操作的角度探索了特征模型一致性演化的可能性（例如，添加、移除和设置特征）及其语义。在我们的方法中，我们提出了一个自动化的方法，提供了一组建议，以确保SPL特征模型及其设计的一致性。自动化通过精确定义每个更改操作的前置条件、后置条件以及对特征模型和设计的影响来实现。我们注意到，我们的方法被设计成在SPL变更的实施或规划期间使用，而不是在SPL演变历史分析期间使用对 于 模 型 演 化 中 的 工 作 量 估 计 ， Ramil 和 Lehman（2000）提出了一套从软件变更记录中获得的软件演化度量。作者认为度量对于工作量估计是足够的。 在我们的工作中，我们提出了一套新的指标，适应SPL的演变和启发Chidamber和Kemerer（1994）。建议的度量（参见第3节）提供了在功能模型级别和整个SPL设计中管理变更影响所需的工作量估计。也就是说，所提出的度量可以用于改变添加或删除的元素（特性、类、属性、方法和包）数量方面的影响。风险管理的目的是减少潜在的风险，并提供积极改善业绩的机会在此背景下，Barry（1991）提出了十大风险类别的列表在最近一篇关于风险管理的论文中，风险因素根据其发生频率进行了优先排序-因此，确定了与其总体影响有关的14个风险因素清单。在Shahzad（2010）中，作者提出了一个模型，可以用来有效地处理软件开发环境中的风险。在SPL演化的背景下，风险是演化的结果，它会影响一致性、完整性和正确性。为了保持一致性，当变化累积时，相关的资产可能会在不同的方向上发生变化，并且它们之间和/或与特征模型不再兼容。当给定的更改应用于大量资产时，完整性会受到影响在演化过程中，关联可能会丢失或重新路由，导致资产从配置中被忽略并阻止进一步更改。当更改资产而不将更改推广到其余资产/特征模型时，正确性会受到影响。在我们的工作中，为每项变更定义的前置条件和后置条件降低了演变的SPL模型不一致和不正确的风险。此外，在我们的工作中的完整性被解释为相对于进化的特征模型的设计的完整性。为了确保一个改变SPL的完整性，我们提出了规则来管理内部（特征模型）和内部（特征模型-设计）演化影响。3. 衡量SPL演进变化为了估计实现渐进式变更所需的工作量，软件工程领域定义了几个度量标准。最著名的面向对象应用程序的度量是由 Chidamber 和 Kemerer （ 1994 ） 提 出 的 。 通 过 类 比 ，Lopez-Harrejon和Apel（2007）对SPL的度量感兴趣。他们定义了几个与特征模型相关的指标，如特征数（NOF），方面数（NOA），类和接口数（NCI），基本代码分数（BCF），方面代码分数（ACF），介绍分数（IF），建议分数（AF）。在我们的工作中，我们提出了一套新的指标，适用于SPL的演变，从Chidamber和Kemerer（1994）的启发。更具体地说，我们感兴趣的是识别在特征模型间/内演化的情况下变更影响管理所需的工作。我们提出了一组变化影响指标，如元素（功能，表1更改与功能对应的影响度量。定义NF计算要素模型中的要素数FNOP计算要素中的包数FNOC计算要素中的类数FNOM计算要素中的方法数FNOA计算要素中的属性数FNOA计算要素中的关联数表2添 加功 能时 更改影响度量。度量定义NF_added统计添加的功能的数量FNOP_added统计添加到特征FNOC_added统计添加到要素中的类的数量FNOM_added统计添加到要素中的方法的数量FNOA_added统计添加到要素中特征FNOAs_added统计要素中添加的关联数表3删除功能时更改影响度量。定义NF_removed统计已删除功能的数量FNOP_removed统计在一个特征FNOC_removed统计在一个特征FNOM_已删除中移除的方法数特征FNOA_removed统计在特征FNOAs_已删除中移除的关联数的特征370J. MaaRizzoun等人类、属性、方法、包）添加或删除。表1给出了对应于特征的不同度量表2和表3分别给出了不同的度量标准，分别用于测量添加特性时和删除特性时所需的工作量。4. 特征模型和设计级变更影响分析SPL可以通过增加一些需求、修改其他需求或删除一些不再有用的需求来发展。例如，现在的手机有各种各样的通用功能，但制造商通过增加功能来吸引消费者，从而寻求产品差异化。这一市场演变触发了手机行业的重大创新。例如，随着移动电话从第一代1G到最新的4G的演进，有必要删除1G在SPL方面，1G相关特征删除导致从SPL设计中删除所有其对应的元素。类似地，4G相关特征的添加必须以与剩余设计元素集成的方式与其相应设计元素（类、方法、属性）的添加对齐。为了确保受控的进化SPL变化，我们提出了一组规则，定义了变化应用的前置条件和后置条件，并在两个级别上识别了必要的变化：（1）FM内变化是相对于属于解空间并对应于特征的工件的变化（例如，添加类、包或一组类及其代码）;以及（2）FM间改变对应于问题空间中特征的演变（例如，添加或删除特征）。4.1. 要素间模型更改FM间的变化涉及特征模型的内部演化，例如添加、移除和修改特征。接下来，我们提出了处理五种不同的FM间演化操作的规则：特征添加，特征删除，特征重命名，特征移动和特征分裂。4.1.1. 添加要素假设开发人员向特征模型中添加了一个特征，并希望将相应的设计片段集成到初始设计中。在这种情况下，变更影响管理包括在保持设计一致性的同时添加与特性对应的设计元素。为了添加元素（类，包，. . ）对应于新特性，我们将使用以下语义标准来表达元素名称之间的语言关系：上位词（C1; C2，.. . ，Cn）：表示名称C1是具体名称C2，. . ，Cn，例如，媒体视频。同义词（C1，.. . ，Cn）：表示名称相同或同义，例如，移动电话和移动电话。str_extension（C1; C2）：表示名称C1是类C2名称的字符串扩展，例如，Image-名称Image。表4列出了添加新特性时应用的规则。这些规则的灵感来自于模型集成的著作（Haddar et al.， 2004年）。例如，在图2中，我们建议添加包含类“PlayAudio”的特征“Hypernyms PlayMedia; PlayAudio类PlayAudio00继承类PlayMedia00现在，假设我们想要添加特性“Mobile”。此功能包含一个 类 “Mobile“ ， 该 类 包 含 一 个 属 性 ”name“ 和 一 个 方法”BullseMedia（）"。在这种情况下，我们应用R3并计算具有最高相似性的类的余弦相似性。在我们的上下文中，我们通过确定两个向量A和B之间的角度来计算它们之间的相似性。向量A包含所有与类相关的术语（类、方法和属性名称）及其同义词。B包含SPL的所有功能及其元素的名称（见图10）。 3）。在我们的例子中，向量A包含元素（class：Mobile，attribute：name和method：BullseMedia（）），向量B包含SPL的所有特征（Media，Audio，Video）及其元素名称（ class ： PlayMedia ， class ： PlayVideo ， class ：AlbumPhoto和class：PlayAudio）。在运行的示例中，余弦相似度的值为0.54，这意味着新类与类“PlayMedia”相似。因此，新类将与类“PlayMedia”有关系。4.1.2. 移除要素假设开发人员从特征模型中删除了一个特征。在这种情况下，变更影响管理包括应用表5中的规则。对于图4的示例，让我们移除具有两个后代“音频”和“照片”的特征“视频”。“视频”是可选的，因此，我们应用规则R4，并使用余弦相似度计算特征“音频”、“照片”和其他特征之间的相似度（Salton和Buckley，1988）。因此，这两个功能将被移动到功能“媒体”。通过删除功能“视频”，属于此功能的所有元素必须表4添加功能的影响。更改名称添加功能新要求前提条件新要素名称与现有要素名称冲击设计R1：如果属于所添加功能的类A的名称是存在于设计中的另一类B的同义词，则这两个类将被合并R2：如果属于所添加特征的类A与设计中存在的另一个类B具有上位词或str_extension关系，则B继承AR3：如果属于添加的特征的类A与设计中存在的任何其他类B没有关系，则用户必须选择类以及与新添加的类的关系●●●软件产品线图2添加功能的示例图3相似度计算。因此，必须根据规则R5和R6删除类4.1.3. 重命名功能一致的命名方案可以提高产品的可维护性，特别是当特性名称暗示产品的功能时。可以重命名功能以反映底层实现更改、采用不同技术或应用程序上下文更改。因此，变更影响管理包括用新名称替换设计中的立体类型4.1.4. 移动特征可以重新组织特征层次结构。将特征从源组合特征移动到目标特征会更改源特征和目标特征之间的父子特征关系。通过移动特征，设计不会改变。例如，在图5中，我们移动特征“音频“和”照片”。因此，这些特征改变了它们的父子特征，而设计没有改变。4.1.5. 分割特征一个特征可以拆分为两个或多个同级特征。如果它是一个复合特征，它的一些子特征将被分布（即，移动到其新的兄弟特征。拆分特征可以通过首先添加新的兄弟特征作为叶特征，然后将一些子特征移动到相关的新兄弟特征来实现。请注意，当将一个特性拆分为两个或多个同级特性时，新特性必须具有与拆分特性相同的特性（参见表6）。例 如 ， 在 图 6 中 ， 我 们 将 特 征 “Media“ 分 成 两 个 特征”AudioVisual“和”Visual”。因此，我们应用规则10，新功能是强制性的，如 分裂的特征。4.2. 特征内模型更改FM内的变化涉及特征的内部演化。它对应于影响属于特征的元素的变化（例如，添加类或包，或者一组类及其代码）。在下文中，呈现了三种不同类型的FM内改变：表5删除功能的影响。更改名称删除要素上下文对象要素条件删除的功能不是强制性的对R4的影响：删除可选功能时，有两种可能的情况：FM ●如果功能没有后代，则将其删除后置条件设计影响功能.根据这种相似度，它们被移动。如果余弦相似度值低于阈值0.7，则后代将不会被删除通过删除特征，必须删除该特征的所有元素。元素可以是包、类、方法或属性。如果一个类被移除，它的所有关系（关联、聚合、组合）都将被移除R5：如果已删除的特征F中的元素（属性、方法、类、包）被另一个特征使用或通过两个特征的结合而关联，则该特征将不会被删除R6：如果类的所有属性和方法都被删除，那么这个类也会被删除● 如果特征具有后代，则有必要计算后代与其他特征之间的相似度。372J. MaaRizzoun等人4.2.1. Add元素SPL可以用新元素（包、类、方法或属性）进行扩展。添加元素时的变更影响规则如表7所示。为了添加元素（类，包，. . ），我们将使用第4.1.1节中给出的R1、R2、R3。例如，在图7中，我们添加类考虑到对FM的影响，我们应用规则R2：Hypernyms PlayMedia; PlayAudio类PlayAudio00继承类PlayMedia00另一方面，对设计的影响在于应用规则R11并添加一个名为“音频”的新功能。4.2.2. 删除元素在某些情况下，会删除设计的某些部分（包、类、方法和/或属性）。删除元素时的变更影响管理规则如表8所示。为了删除元素（包，类，方法.. . ），我们应用规则R5，R6，已经在第4.1.2节中提出。例如，在图8中，我们建议删除类“PlayVideo”。请注意，特性“Video“仅包含此类。因此，对FM的更改影响在于应用规则R12，因此，功能删除.另一方面，对设计的影响在于应用规则R5。因此，当 应 用 R5 时 ， “PlayAudio“ 和 ”PlayPhoto“ 将 从类”PlayMedia“继承，如图所示。8 .第八条。4.2.3. 电子元件当为类、方法或属性等实体分配新名称时，变更影响管理包括自动更新所有相关的名称（引用）、方法调用或属性引用，以保持FM和设计的一致性4.3. 影响分类当设计师有一个新的需求，涵盖了一个（大）集的变化，功能模型，然后变更咨询委员会（CAB）产生一个报告，其中包含所需的额外更改的数量，以确保设计图的一致性。CAB可以根据变更对开发过程的影响来评估要进行的变更。为了帮助CAB做出决策，并帮助他决定要做的改变，一个替代方案是对影响进行分类。这种变更分类允许确定变更是否可行。影响的分类意味着对影响的类别进行分配，图4一个特征移除的例子。软件产品线的变更影响分析373图5是说明移动特征时更改影响的示例。影响重大：变更影响业务关键型基础架构的主要部分它以相当大的规模引进了主要的新5. 为例到决策当局。这一类别可以是边缘性的、实质性的或关键性的：影响边际：变更与单一产品相关，可以安全地排除副作用。添加特性或其元素（类、方法、属性）、拆分和重命名特性被归类为边际影响。重大影响：变更影响SPL的多个产品，或者影响IT基础设施的基本部分它影响强制特征或与另一特征具有排除/要求约束的特征删除功能或功能的元素被归类为实质性影响。为了说明我们的方法，我们使用文本编辑软件产品线作为案例研究。该系列有八种产品变体。每个产品实现一个简单的文本编辑应用程序。FM中收集的功能用于指定这些产品之间的差异。文本编辑系统的特征模型如图9所示。请注意，特征的数量为30。为了帮助用户管理变更影响，同时保持SPL功能模型和设计的一致性，我们开发了一个名为“Evo-SPL”的工具。Evo-SPL的主要功能是根据度量标准自动计算变更影响所需的工作量，并在演化后生成新的一致SPL设计和特征模型。事实上，用户在任何演化之前输入特征模型和设计，然后他将更改应用于特征模型和设计。之后，Evo-SPL验证规则并验证特征模型和SPL设计。特征模型和设计之间的可追溯性与我们的UML概要文件。最后，使用我们的工具测量影响分析所需的工作量。源特征模型作为XML文件输入到工具中。然后，他选择了进化的类型。(i.e.、特征模型或设计的演变）。用户可以添加、拆分、删除或重命名特征。此外，他可以添加，删除或图6是一个示例，说明了拆分特性时的更改影响。表6拆分要素的影响。更改名称 拆分功能上下文要求更改条件新要素的名称必须与现有要素名称对R7的影响：如果某个功能是可选的，则将其拆分为必须是可选的新FMR8：如果一个特性是强制性的，它将被拆分为必须是强制性R9：如果要素F1与另一要素F2具有"对R10的影响：每个元素（类、包、方法、设计属性）都以拆分的名称要素F1将替换为新要素●●●374J. MaaRizzoun等人因此，适用规则R3。类“Basic“和其他类（类名称、方法、属性）之间的相似性计算的最高值然后，我们的工具建议用户选择新类“Basic”和类“Text”之间的关系（关联，聚合和组合）。在我们的例子中，他选择了一个关联关系。变更2：删除特征拆分。更改影响：我们注意到可选功能根据这个相似度，我们注意到“splitVertical“和”chang eDisplaySettings“之间的余弦相似度然后，将类似地，计算“splitHorizontal“和”Unsplit”的余弦相似度。因此，重命名一个元素，它可以是一个包，