一般来说，可变性建模瞄准呈现产品线共性和可变性的一个概述。根据可变性建模形式，通用性要么只能间接解决，也就是说，一切没有明确定义为变量的要隐式定义为共性的；通用性要么只能直接解决，也就是说，某些方面明确定义为共性的，目的是强调它们，并记录决定、使它们成为共性的。为了强调变异性建模也至少间接解决了通用性这个事实，有时更喜欢使用术语共性/可变性建模。

如同所有的建模活动的情况，可变性建模试图通过抽象实现其目标。这意味着与一个产品线变化相关的整个信息的一些方面故意被排除在外，以把信息量减少到可控水平，并强调重要方面，同时又隐藏不必要的细节。

然后在一个变异性模型中捕获的信息，作为在组成产品线基础范围内定义可变性的基础，并作为配置各个产品实例的基础，从基础上派生出可变性。例如，考虑一个ML/SL模型，其中某确定的模块B₁必须被其他模块B₂替换，它取决于选定的产品实例。为配置各个产品实例（即选择和定义它们）提供基础，并为定义何时B₁不用替换就可使用以及什么情况下需要用B₂替换B₁提供基础，是产品线变异性模型的责任。如何进行的细节在很大程度上取决于可变性建模技术的应用。我们将在7.5节中详细描述这一特征模型。

大约可以区分三种形式的变异性建模模型：特征建模、决策表和决策树/图。图7.2显示了参考文献中[MJA⁺04]提出的一个决策表的摘录，它是德国（凯泽斯劳滕）Fraunhofer IESE研究的PuLSE方法的案例研究。一个决策表通常是指一个或多个变量的研发产品，在案例中，一个决策表是一个用例图，用于表示使用案例“发送消息”（未显示）。决策表中的每一行代表一个要采取的决定，以配置表中相应变量（S）。每一个这样的决定有：

•一个ID（例子中的一个普通的数字）。

•制定应采取决策的问题。

•用于从语义上给多个相关决策分组的主题。

•列出可能的决议，即对问题可能的答案。

•每个决议的一个影响，描述了相应的变量必须如何改变，以配置它们与所采取的决定一致。

图7.2 摘录的样本决策表

在决策表中，每列的数量和确切含义随方法而变，但这里给出的例子说明了决策表的基本思路。约束是决策的其他重要特性的一个案例。使用约束，可以定义决策之间的相互依存关系，以限制取决于提前采取决策的可用的决议，或当因为一些更早采取的其他决策不再有效时，隐藏决策。例如，如果决定“手机有照相机吗？”得到的回答是“没有”，则决定“相机的分辨率是多少？”不再是有效的，且可以在配置中隐藏。同样，决策表的决策有时可以分层组织。

同样，定义决策树应采取的决定是为了配置一个或更多的变量。然而，决策要表示出来，并用图形排列。图7.3展示了这样一个决策树的例子。决策树的优点就是决策之间的一些选择的依赖关系可以很容易地以这样的方式定义。例如，决策“相机是什么分辨率？”在该相机被拆的情况下是无效的，尽管它在决策树上是可见的。可能的产品配置数量也很容易检测到，因为决策树的每一叶对应于一个产品配置。然而，这一点也正是决策树的一个重要问题。在复杂情况下，决策树往往变得非常大。这可以通过使用定向非循环图（即一个“树”的节点可能有一个以上的根）来避免。

在这一章给出的汽车产品线概述的其余内容中，我们不考虑决策表和决策树的更多细节。相反，我们将集中在特征建模，它可能是最流行的变异性建模形式。

图7.3 决策树案例

7.3.3.1 什么是特征？

在详细介绍特征建模之前，我们首先给出对特征这个词的一个简短讨论，它是所有特征建模技术的基础。当我们谈到工程师和从业者在采用特征建模和产品线技术的早期阶段，我们通常承认有相当大的不确定性，且不满意特征的概念和特征建模。主要的批评是，特征一词具有非常模糊、不明确的含义，或在汽车业内，对特征这个词存在很多不同的理解，甚至在单独一个公司内对这个词也有不同理解。这往往导致试图为特征一词提供一个更具体的、特定的含义，例如，“一个组件”“一项功能”或“用户可见的功能需求”。虽然这样的专业或分类在某些情况下可能具有价值，但是我们相信在一般的、公司层面（甚至超过），它们是非常成问题的，且会导致滥用特征建模，这是由于术语“特征”的广泛含义是与该方法的强度密切相关的。

就像一般的可变性建模，特征建模也是瞄准介绍产品线产品之间的共性和可变性的概述，并瞄准支持产品配置。但与决策表和决策树/图相反，特征建模并不关注配置过程中所采取的决策，也不关注对变量造成的影响。相反，特征建模的重点直接在于产品线各个产品之间的差异和相似性。更具体地说，特征模型列出各个产品的所有重要特性，并说明这些特点对所有产品是否常见——也就是每个产品和每一种产品显示出给定的特性；或特性从一个产品到另一个产品是可变的——也就是一些产品展示出这一特点，而另一些产品则没有。由于产品之间存在的不同特性，可能具有非常多样化，所以我们需要一个充分抽象的术语来表示这些特征，即术语“特征”。这就是为什么它是这样一个广泛意义上的好东西。

因此，术语“特征”可以定义如下：特征是特性或是在最广泛意义上的特质，它是一个产品线的每个产品实例可能拥有或不可能拥有的。

几点结论归纳如下：

•一个特征是可以存在于一个产品实例中或不存在。这意味着在产品配置中，它可以被选择或它被取消选择。

•特征并不一定对应于一个子系统或部件（特征可以对应一个子系统，例如，“气候控制”或“防抱死系统”；但这并不是必需的，例如，特征“低能耗”）。

•一个特征不需要用户可见。

•一个特征不一定是一项功能要求。

总之，特征这个术语的极端宽泛性是由于特征建模发生在高度抽象造成的。这就是特征建模的力量，否则如果术语“特征”有一个更精确的含义的话，那么特征建模将无法达到目的。

7.3.3.2 基本特征模型

特征模型的目的是用一个图形化的形式显示产品线的产品实例的共性和可变性。在特征树形式中的基本特征模型是由Kang等介绍的。图7.4显示相同的小特征树例子中两种常见的符号。

图7.4 基本特征模型的两个替代符号的案例

特征表示为树的节点，例如，巡航控制或刮水器。有时，根节点被看做是一种特殊的实体，称为概念。但最近它变得不再受欢迎，因为它引入了一种没有真正的需要的特殊情况。

特征具有层次结构：先辈特征可以有一个或更多的子特征，用线从先辈连到子。在语义层面上，这意味着只有当先辈的特征是存在时，一个子特征才有可能。因此，先辈-子的关系和由它们导出的特征树的层次结构可以被视为特征之间的一个特殊的符号，这是对于一些但不是所有的依赖关系来说的。

需要出现在所有的产品实例（包含它们的先辈）中的子特征，称为强制性特征，它们用实线表示并连到它们的先辈或实心圆上（例如，刮水器）。非常重要的是要注意到，就它们出现在产品线所有产品这种意义而言，强制性特征并不是在所有情况下是强制的。例如，刮水器出现在所有产品实例中，而加速执行器只出现在有巡航控制这样的产品中（但在所有车型上都有这些巡航控制）。作为一般规则，强制性的特征是通用性，即它是出现在所有产品实例中，当且仅当它的所有祖先因素是强制性的。相反，可选特征是只在某些产品实例上出现的特性，它们包含它们先辈（的特征），因此在配置过程中需要直接选择或取消选择。它们用虚线表示，并连到先辈或一个空的圆圈上（例如，巡航控制、雷达、雨量传感器）。可选特征从来不代表通用性。此外，同父的两个或两个以上的子特征相互排斥被称为备选特征。它们的父子关系用圆弧连接（例如，简单和自适应是两种刮水器备选形式）。准确地说，两个或两个以上的备选特征必须在一个产品实例中存在，当且仅当它们的父辈是存在的。因此，在配置过程中，当选择了父辈时，它的备选子特征之一必须选择。

因此，两个语义相同的特征模型（图7.4）要做如下解释：一辆车总是有刮水器（或称为雨刷），并可以选择巡航控制。刮水器可以带一个雨量传感器。巡航控制总是需要一个电子执行器，为的是能够影响加速度。存在两种备选形式的巡航控制：简单巡航控制就是简单地保持加速度在一个恒定值；自适应巡航控制就是保持车辆速度在一个恒定值（例如，当车子开上斜坡时，通过增加加速度来保持车速）。此外，该车可配备雷达。在这种情况下，当汽车与前车之间的距离低于一定的阈值时，车辆速度会降低。请注意，并非这里给出的所有的信息被特征模型所捕获，例如，先进的巡航控制的含义并不明显。这些信息将在一个特征文本中描述（图中未表示）。(www.daowen.com)

最后，特征之间的额外依赖关系可以特征链接形式在特征树中定义。这些通常有助于进一步约束一组有效配置。例如，如果雷达和雨量传感器在车身内使用相同的安装空间，那么可以在雷达与雨量传感器之间用一个双向箭头定义一个特征链接，并用标签“排除”表示。特征建模技术有很大的区别：在于它们提供什么类型的依赖关系链接，一些干脆把这个链接打开。典型类型的依赖关系有“排除”（双向）和“需要”（单向）。如果A排除B，若B存在，那么A可能就不存在；反之亦然。如果特征A需要特征B，若B缺失则A可能不存在；但没有A时B可能存在。其他特征链接在配置过程中可以向用户给出建议，比如，如果特征A“建议”B，则这意味着你可以选择A而没有B，但你应该有一个好的理由去做这些。

尽管具有共同的树形式，但特征树与决策树有很大的不同。首先，节点代表特征，其中产品实例彼此不同，替代了配置过程中需要回答的问题。虽然特征可以被解释为问题（例如，特征巡航控制可以解释为问题“汽车具有巡航控制吗？”），但这才是真正的可选特征。第二，一个特征树结构是通过说明每个特征是否被选中来给出，而一个决策树的配置是通过精确选择树叶节点（或从根到叶的一个完整路径）来给出。第三，决策树定义了一个次序，其中决策是计划采取的，因此优化了决策，它对约束条件的实际效果具有显著的影响。

在本节的其余部分，将介绍一些先进的特征建模的概念。这些可以被看做是对基本特征建模的一个可选扩展。

7.3.3.3 基于基数的特征建模

基本特征建模的一个重要的扩展是基于特征建模的基数。根据这种方法，每个特征都分配一个基数——类似于统一建模语言（UML）类图基数（例如，[0..1]，[1]，[0..*]，[0..4，8..12]）。基数[0..1]意味着相应的特征是可选的（例如，图7.5中的巡航控制和雷达），[1]意味着特征是强制性的，1以上的最大基数意味着特征可能不止一次出现在一个单一的产品实例中。同父的几个子特征可分在一组特征中。这些特征组也有一个基数，它说明对应组有多少个特征必须或可以被一个单一产品实例所选中。例如，一组基数[1]是指每当它们的父辈被选中（例如，在图7.5中的简单与自适应），则只有组特征中的一个特征需要选中。这相当于基本特征模型中的备选特征。

图7.5 具有先进概念的特征模型的案例

除了把概念强制性、可选的和对单一、共同基数概念的替代作为基础外，可以看到的基于基数特征建模的主要贡献在于具有最大基数大于1的特征，它被称为克隆特征。在配置过程中，这样的特征可以进行多于一次的选择。在这种情况下，克隆特征的后代可以为每次克隆特征的选择分开配置。例如，在图7.5中，特征刮水器必须至少选择一次（前刮水器），但也可以选择两次（前、后刮水器）。在后者情况下，是否让刮水器配备雨量传感器的决策可以采取对前刮水器和后刮水器分别考虑。在图7.5的右侧，采用基本特征建模方法进行说明。然而，发现两个表现手法之间存在微妙的差异：基于基数的符号并不包括两个刮水器特征代表前、后刮水器的信息，也不包括强制性是前刮水器的信息。此外，例如两个刮水器配置之间的依赖关系，比如，后刮水器仅能在前面刮水器也有一个雨量传感器时，配备雨量传感器正如图中“需要”链接所定义的，不能容易地用基于基数的特征建模来表示。

对于最大基数为2或3、有时也许是4来说，克隆特征的概念可以很容易地与基本特征建模概念交换。对于更大的顶级基数，原则上也是可能的，但特征模型变得非常庞大，且在这些情况下变得高度冗余。对于无穷大顶级基数（即特征可以选择任意次数）来说，当然这是不可能的。因此，克隆的特征主要用于其他方面，而不是前、后刮水器上。克隆特征变得特别有用的一个典型案例，就是在一个控制器局域网络（CAN）上配置若干ECU（可以），连同它们的操作系统、安装的驱动程序以及应用层上的软件任务。

7.3.3.4 具有若干个父特征的特征

具备克隆特征的类似目标和结果的一种先进的特征建模概念是多父特征。使用这一概念，特征树变成了有向无环图。相对于一个父辈来说，子特征是可选的，而与此同时，相对于另一个父辈来说，则是强制的。相对于n_man（n_man≤n）个这些父辈来说是强制性的、具有n个父辈的特征f，可以解释为具有基数[n_man…n]的特征。例如，在图7.6中的刮水器是前风窗玻璃与后风窗玻璃两者的一个子特征。前风窗玻璃总是有一个刮水器，而后风窗刮水器是可选的。就像是克隆特征情况，当选择多于一次时，特征刮水器每次将分别配置选择。这意味着在一个案例中，前风窗玻璃刮水器可能有雨量传感器，而在后风窗玻璃刮水器可能没有一个雨量传感器，反之亦然。

上面描述的大多数克隆特征问题也适用于具有多父的特征。一个重要的区别是，多父特征提供有更多语义特征，这是因为它们固定在不同的父辈之下，如图7.6所示。

7.3.3.5 参数化特征

此外，一个特征可能具有某种类型的一个属性，并称为属性特征。与特征的基本属性如名称和描述相比，这个属性具有完全不同的性质：后者（基本属性）的值是在特征树定义过程中规定的，属性特征值是在特征选择过程中规定的，从而成为产品配置的一部分，而不是特征模型的定义。因此，在产品配置中，一个属性特征不仅有状态“选择”或“不选择”，这意味着它会集成到产品中或不会这么做，而且具有一个值，当且仅当特征被选择时，这个值可能是一个字符串、整数或浮点数。其他类型也可以想象。

不幸的是，这种常见的术语易于混淆不同的属性，即基本属性（如名称和描述）和非基本属性。因此，我们赞成把非基本属性称作参数，并把具有这样参数的特征称作参数化特征。图7.5给出了一个参数化特征的案例。特征雷达是支持使用int类型声明（整数）。在配置过程中，当雷达特征被选择时，一个整型值必须提供来指定最小允许距离。再一次说明，事实上，具有这种含义的参数值只能在特征文档中捕捉到。

图7.6 多于一个父辈（或根）的特征案例

通常，特征参数是这样定义的：单一特征可能只有单一参数（不是几个），这经常招致汽车工程师的批评。这个限制的基本原理是：当一个特征需要一个以上的参数时，喜欢为每个参数添加子特征，而不是直接把参数添加到单一特征上。否则，在各个参数中分开捕捉到的信息将是“隐藏”在参数列表中，虽然这是非常适合于在特征模型本身中捕获的信息。根据我们的经验，在大多数情况下这是真的；但在某些情况下，额外的子特征变得非常虚假。因此，从我们的角度来看，存在两种解决方案的很好理由，因此它主要是口味的问题。

7.3.3.6 配置决策

产品线工程的经典应用程序域是标准的桌面应用程序、操作系统的研发以及类似的域。在这些域中，特征模型通常是交互配置的：当一个特定的产品实例是必要的时候，既可以由客户直接配置，也可以由工程师密切配合客户来配置。在汽车领域和可以说很多其他嵌入式系统领域中，这是不可行的。汽车制造商的特征模型可以很容易地包括成百上千的特征，它们中的部分特征是纯粹技术的，且最终用户也看不见它们。不是手工配置这样的特征模型，有必要事先定义每个特征有什么情况及在什么情况下会选择它们。

在简单的情况下，这可以通过把一个逻辑表达式连接到每个特征上来完成。这些表达式称为选择标准。当且仅当一个特征的选择标准为真时将被选中。虽然对于简单情况是完全足够的，但是对于复杂的特征模型来说，选择的标准变得非常难以维持。这是因为各个因素驱动的配置定义常常是分散在许多不同的特征选择标准中，且影响单个特征选择标准的几个这样的考虑被编译成一个逻辑表达式，然后可以不再加以区分。因此，对于复杂的工业产品线，这种方法是不可行的。

特征模型配置的一个更先进的概念是配置决策。它们以一个高度可扩展的形式，允许在另一个特征模型的配置中定义一个特征模型配置。这样配置和被配置的特征模型之间的一个链接，称为配置链路。

这样的配置链接实例的说明如图7.7所示。让我们假设存在三个因素影响巡航控制特征模型的配置：

图7.7 采用配置决策来定义特征配置

•所有的北美汽车必须有一个巡航控制，因为这个特征由这个市场上的客户作为标配期待（营销决策）。

•所有的北美汽车必须配备自适应巡航控制，因为我们的主要竞争对手把它当做标配（营销决策）。

•加拿大的汽车必须包括自适应巡航控制系统。国家立法要求这个（管理决策）。

这种情况是按照三种配置决策进行建模的，如图7.7中的表所示。每个配置决策纳入标准，说明针对什么样的产品实例的决策是有效的。这样的纳入标准定义了一组产品的情况，称为产品设定。其次，针对每个决策，配置的特征模型的几个特征都要一一列出，它们被包括或排除（本案例中没有显示）在决策产品设定的所有产品实例中。最后，每个决策提供一位负责人和理由。当配置特征模型的一个特定设置提供后，可以通过组合配置决策，导出配置的特征模型的设置，这些配置决策对应于配置特征模型设置的产品实例是有效的。

当考虑案例中的冗余时，分开记录单个配置决策的好处变得愈加明显。当对每一个特征使用一个选择标准时，三点考虑都会被编译成一个单一规则：北美汽车都配备自适应巡航控制。然而，当一种考虑改变或停止使用时，明确分离考虑对建立变化对配置的影响，一般具有非常重要的意义。例如，当竞争者改变产品序列，且它们不再把自适应巡航控制系统作为标配时，那么第2号配置决策就变得无效。在这种情况下，非常重要的是要知道，还有其他的理由使北美汽车搭载自适应巡航控制系统。同样的，当新的考虑出现时，有可能检测到与现有的考虑冲突；然后，冲突的配置决策的理由可以咨询，或负责人可以联系以解决冲突。

存在配置决策的许多额外属性是可能的，例如在时间的优先次序上或限制的有效性。

7.3.3.7 其他先进特征建模概念

特征建模的许多其他概念已在文献中提出。例如，特征树的边缘——也就是父子关系——可以键入，目的是指定子特征是否是一个特例（在上面的例子中的简单和高级），或父特征的一部分（巡航控制、刮水器）。同时，特征可以被组织细化成若干层。先进的特征建模的概念的更多细节超出了本章的范围。