在核心资产存储庳的所有资产中，软件构架是重中之重。构建一个成功的软件产品线 的本质就是区别在产品线家族的所有成员中，什么会保持不变，什么会发生变化。软件构架在构建时已经为处理这种两重性做好了准备，因为所有的构架都是承认存在众多实例的抽象：毕竟，其主要的概念价值就在于能够使我们把重点放在大蛩不同实现中的设计要点 上。构架非常本质的特性就是它论述了我们希望在构架中什么保持不变，以及允许什么发 生变化。在软件产品线中，构架就是不变化的方面的表示。
但是，对于产品线构架则不能采用这一简单的方法来划分，该构架中有一组明确允许 发生的变化，然而对于常规的构架来说，只要满足了（单个）系统的行为和质量目标，几乎任何实例都是可以的。因此，识别允许的变化是构架责任的一部分，同时还需提供内建的机制来实现它们。这些变化可能会非常大。软件产品线中的产品同时存在，但这些产品在行为、质量厲性、平台、网络、物理配置、中间件以及比例因子等方面可能是不同的。 产品线设计师擗要考虑以下3件事情：
• 确定变化点
•支持变化点
•对产品线构架的适宜性进行评估
14.4.1确定变化点
确定变化是一项需耍持续进行的活动。因为产品可能会以很多方式发生变化，因此实 际上可以在开发过程的任何时间确定变体。一些变化是在产品线的潘求获取过程确定的；
一些变化是在构架设计时确定的，还有一些变化是在实现时确定的。也可以在第二批（以及随后的）产品的实现期间确定变化。
在需求过程中发现的变化可能包括特性、平台、用户接口、质量厲性和目标市场。
一些变化是相互依赖的。例如，用户接口可能与使用的平台有关，反过来这可能又与特定的 目标市场有关。
在构架设计过程中发现的变化点可能是实现在需求获取过程中确定的变化；或者是设 计中的正常变化，因为某些决策只有在获得更多的信息后才能确定。在任何情况把这 叫做变化点都是适当的，因为构架中存在捕获该变化的地方。
14.4.2支持变化点
在个常规的构架中，实现不同实例的机制几乎总可以归结为修改代码。但是在软件 产品线中.对变化的构架支持可以有多种形式：
• 包含或省略元素。该决策可以反映在不同产品的构建过程中，或反映在可以根据 某个指出其存在或不存在的参数有条件地进行编译的元素的实现中。
• 包含一个不同数量的复制元素。例如，可以通过添加更多的服务器产生高容量的变体一作为一个变化点，应该没有指定实际的数量。此外，build文件将选择适 合某个特定产品的数量。
• 具有相同的接口但具有不同的行为或质量属性特性的元素版本的选择。选择可能 会在编译时或构建时发生，某些情况下甚至是在运行时发生的。两种选择机制为 舴态库和动态链接库，前者包含在编译时后链接到的外部功能.后者具冇静态库 的灵活性，但把决策推迟到了基于上下文和执行条件的运行时„通过改变库，我 们可以改变名称和签名己知的功能的实现。
这些机制在构架级产生了大规模的变更。可以引入改变某个特定元素各方面的其他机 制。改变源代码就属于此类改变。更复杂的技巧包括：
• 在面向对象的系统中，特化或泛化特定的类可以实现变化。可以编写类以容许根 据需要为各种产品编写的多种特化。
• 把扩展点构建到元素的实现中。这是-个可以安全地添加额外的行为或功能的地方。
• 可以通过在元素、子系统或子系统集合中引入构建时参数来实现变化.由此可以 通过设置-组值来对系统进行配置。
• 反射是程序对其本身或其执行环境或状态操纵数据的能力..反射程序可以根据其 上下文调整其行为。
• 过载是重用指定的功能以对不同的类型进行操作的手段..过载促进了代码重用， 怛要以可理解性和代码复杂性为代价。
当然，对于产品线的构架（保存在核心资产库中）和毎个产品的构架来说，必须为其 编写文裆（参见第9章）。为每个产品的构架编写文档要以能与产品线的构架区分开来为 准。产品线构架的文挡应该消楚地说明其变化点以及每个变化点的基本原理（很可能使用 范围定义进行说明）。它还应该描述构架的实例化过程，也就是如何应用其变化点。从理 论上说，应该可以单独描述每个变化点，但实际情况并非如此。可能有些组合从来没有使用过，更糟糕的情况是有可能会导致错误，因此构架文档需要解释有效的和无效的变化 绑定。
可以根据与变化点的偏差或变化点的绑定来编写每个产品的构架文档，例如，16号产 品的构架可能耍求有3个服务器、64个客户机工作站、2个数据库、高速低分辨率的图形元素以及消息生成器中的空加密。
14.4.3产品线构架评估
与任何其他构架一样，也应该对软件产品线的构架的适宜性进行评估。实际上*由于 有很多系统采用该构架，因此对产品线的构架进行评估显得更为重要。
本书已经讲述的评估技巧非常适用于对产品线的构架进行评估。应该对构架的健壮性 和-般性进行评估.以确保它可以作为产品线所构想范围中的产品的基础。为了确保构架 满足了当前所开发产品的具体的行为和质量需求，也应该对构架进行评估。我们先重点讨 论-下评估的内容和方法，然后讨论评估的时间。
评估的内容和方法。必须把评估的重点放在变化点上，以确保它们是适当的：它们 提供了足够的灵活性，从而能够覆蛊产品线的预期范围：它们支持快速构建产品；它们不 会产生不可接受的运行时性能成本。如果评估是基于场景的，则耍获取涉及将构架实例化 以支持家族中的不同产品的场景。此外，产品线中的不同产品可能具有不同的质量i厲性需求，必须对构架提供所要求的组合的能力进行评估。在这.里，仍然需要获取捕获了产品线 家族成员所要求的质量属性的场景。
通常情况下，在最初开始时，产品线构架的•些硬件和其他影响性能的因素是未知的。
在这种怙况下，评估可以确定构架能够实现的性能的边界，并对硬件和其他变化的因素假 定一个边界，该评估可以确定潜在的冲突，从而使您准备好用于解决冲突的策略和政策，
评估的时间。应该对用于构建产品线中的•个或多个产品的构架的实例或变体进行评 佔。是否对产品的构架进行单独的、专门的评估取决于该构架与产品线构架在影响质量属 性的方式上有多大差别，如果没有差别，则可以简化产品线构架评估，因为将会在产品线 评估中处理许多通常会在对-个产品的评估中提出的问题。实际上，正如产品构架是产品 线构架的一个变体一样，产品构架评估也是产品线构架评估的-个变体。因此，取决于所 使用的评估方法，评佔制品（场景、检査列表等）将具有重用的潜力，在创建这些制品时 应该把这点记在心上。产品构架评估的结果通常能给产品线设计师提供有用的反馈，并 推动构架的改进。
当提议开发的•个新产品不在最初的产品线的范围内时（大概已经对该产品线的构架 进行了评估）.则可以重新对产品线构架进行评估，看看该构架对这一要开发的新产品来 说是否已经足够。如果已经足够，可以扩展产品线的范围，使其把新产品包括在内，或者 产生一个新的产品线：如果不够，可以通过评估确定必须怎样修改构架，以使其容纳新的 产品，
对产品线和产品构架进行评估不仅能确定构架风险，而且还能够使用CBAM (参见第 12章）确定哪些产品将产生最大的回报。
14.5采用软件产品线的困难之处
成功采用产品线需要幵发组织具备一定的经验。技术并不是惟一障碍；组织、过程和 商业问题对全面获得软件产品线方法的优势同样重要。
软件工程研究所确定了影响到组织采用软件产品线成功与否的29个问题或“实践区 域'。 在这些实践区域中，大多数也在单系统开发中应用，但在产品线上下文中呈现了-个新的维度。两个示例为构架定义和配置管理。
对于任何项目来说，构架定义都是一项重要的活动，但正如我们在上一节中所看到的， 需要强凋软件产品线中的变化点。对于任何项目来说.配置管理也是•项重要的活动.（但对软件产品线来说.配置管理更加复杂，因为每个产品都足绑定大量变化的结果„产品线 的配置管理问题就是复制交付给任何客户的任何产品的任何版本，这里的产品指的是代码 和支持制品，从需求规范和测试用例到用户手册和安装指南。这包括了解在产品构造中使 用了毎个核心资产的什么版本，如何对每个资产进行剪裁以及添加了什么专用代码或文 档。
分析产品线生产的每个方面已经超出了本书的范围，但下一节将对几个关键方面进疔
分析，以使您了解产品线和单系统开发在性质上的不同。这些问题是组织在考虑是否采用 产品线进行软件开发时所必须面对的-
14.5.1所采用的策略
像采用任何其他新技术一样，要使组织采用产品线方法并不是轻而易举的事情。如何 解决这*问题取决于组织的文化和背珉。
当管理人员决定组织将采用该方法时，就是自上而下的采用了产品线方法。采用这种 方法时.需要使埋头苦干的员工改变其工作方式。当在产品级工作的设计人员和开发人员 意识到他们没必要重复彼此的工作，幵始共莩资源并开发共有的核心资产时，就是向自下而 上地采用了产品线方法。采用这种方法时，需要找到一位支持采用产品线方法，并使组织 的其他部门也采用该方法的管理人员。这两个方法都很有效：都需要有位产品线方法的 侣导者给予极大的帮助，这位倡导者绝对相信产品线的巨大作用，可以勻其他人共享这一 非常有说服力的构想。
与技术将朝着哪个方向发展这一问题不相关的是产品线本身将如何发展。下面给出了 两个主耍的模型。
在“前晚性”的产品线中，组织使用一个广泛的范围来定义产品线家族。他们是利用 其在应用领域的经验、对市场和技术发展趋势的了解以及出色的商业判断力，而非使用水 晶球（•种石英水晶球或玻璃球.占卜者被设想能够看到其中的图像.尤指那呰被认为能 预测未来的图像）来建立“前瞻性”的产品线。在两个产品线发展模型中，前晚性的模型 是最强大的，因为它能够使组织制定最深远的战略决策-明确界定产品线的范闱能够使您 发现市场中需耍哪些尚未开发出來的产品，从而对产品线进行小的扩展.快速填补这•空 缺。简而言之.前瞄性的产品线范围能够使组织牮握自己的命运。
有时候.组织并不能利用前瞻性模型所暗示的确定性来预测市场的需要。大概因为这 是一个新领域•或者该市场正处于变化之屮.或者组织没有足够的资金立刻构建•个涵盖 整个产品线范围的核心资产库。在这种情况下，组织更有可能采用一个“反应性”的模型。 在这里，组织是根据以前的产品构建产品家族中的一个或多个成员。随着每个新产品的开 发.构架和设计方案都根据需要进行了扩展，而且核心资产库是根据“已经证明"为共有 而非“预先计划”为共有的元素构建的。反应性模型不太强调预先规划和战略方向的确定。 相反，组织是在市场的指挥棒下运作的。
①这些模型是由Charles Krueger T•城近在Dagstuhl召开的软件产品线丁作会议t提出来的
了解各种模型有助于组织选择适合自己的模型。前瞻性模型需要进行初始投资.但很 少返工：反应性模型几乎没有初始投资，但需要进行大量返工。对于某个特定的组织来说，
采用哪个模型作为指导主要取决于组织的情况。
14.5.2创建产品并演变产品线
拥有产品线的组织将会有-个构架和一个与之相关的元素集合。组织时常会创建产品 线的一个新成员，它不仅具有与产品线中其他产品相同的特性，而且具有不同的特性。
与产品线相关的-个问题是如何管理其演变。随着时间的推移.产品线——尤其是用 以构建产品的核心资产集——也必须演变。该演变主要逛由外部和内部源推动的。
外部源
• 由其厂商发布该产品线中元素的新版本，将来的产品需要根据这些新版本的 元素构造。
• 可以将外部创建的元素添加到产品线中。例如，某些原来由内部开发的元素 完成的功能现在要改由外部开发的元素来完成，或者反之。或者是将來的产 品要利用新技术，而这些技术包含在外部开发的元素中。
• 可以向产品线中添加新特性，以满足用户霈要或适应竞争的需耍„
2.内部源
• 必须确定向产品中添加的新功能是否在产品线的范围内。如果是，就可以很 简单地利用产品线的资产库完成新产品的开发。如果不是，就必须做出决策: 或者把增强的产品从该产品线中独立出来进行演变，或者扩展资产库，使其 包括这些新功能。如果在将来的产品中很可能也耍用到这些新功能，则更新 产品线应该是最明智的选择，但更新产品线的核心资产需要时间。
• 如果产品线的资产发生了变化，即使组织可以收回已构建的产品，并用裉据最新资产库构建的产品更换，它也不应该这样做。使产品保持与产品线的兼 容性需要花费时间和精力，但如果不这样做.可能就会使未來的产品升级花费更多的时间。这是因为该产品必须与当时最新产品线元素•致，否则将无 法利用产品线中添加的新功能。
14.5.3组织结构
产品所依赖的资产库有自己的演变之路，它要求组织决定如何管理它和产品的发展。 Jan Bosch [Bosch 00b]研究了产品线组织模型.并确定了如下4种类型：
(1)开发部门。所有软件开发都集中在一个单元进行。我们希望单元中的每个成员 在产品线开发屮都是•个多面手，可以在需要时进行领域工程设计或应用工程设计.小型
组织和提供咨询服务的组织•般采用该模型。尽管该模型很简中-，且交流起来比较方便， 但仅有一个单元还是有很多明显的缺点。Boscb认为这种模型可能只适用于最多30个人的 单元（而这对我们来说已经很多了），但在很小的组织中，其产品线也很小，这可能是一 个可行的方法。
(2)业务单元。每个业务单元负责产品家族中系统的•个子集，这些子集根据相似 性群集到•起。共亨资产由需要它们的单.元开发，并提供给团体：开发新资产的业务单元 之间可以进行协作。该模型具有变体，这取决于业务单元在开发（或修改共亨资产）中的 灵活性如何。如果没有限制的话.产品在其演变路径上会不同，从而使产品线方法无法发 挥应有的作用。将某些特定资产的责任分配给具体的业务单元，他们必须维护其资产，以 供整个产品线使用。要求其他业务单元利用这些资产。Bosch估计该模甩可用于员工数在 30〜100个之间的组织。该模型所存在的很明显的风险是，业务单元首先将把重点放在其 自己的产品上，而把整个产品线放到次要地位。
(3)领域工程单元。指定个专门的单元负责核心资产库的开发和维护，业务单元 根据这些核心资产库构逑产品。Bosch指出当组织的员工数超过100时，单独的业务单元之间的交流渠道就变得难以招架了，建立一个到中心共亨资产单元的渠道就变得很有必要 了。在这个模型中，需要一个强大的、规范化的过程，以管理各单元之间的交流，并确保 产品线的良好运作是所有各方的目标。
(4)分层次的领域工程单元。应该分层看待一个很大和/或很复杂的产品线。也就是 说.产品线可以由子群组成.与产品线中的其他成员相比，这些子群中的成员具有更多的 共同之处。在这种情况下，一个领域工程单元为整个产品线开发共享资产，另-个领域工 程单元为专门的子群开发共享资产。这个示例有两个层次，但是，如果子群具有专门的子 子群，则可以对该模型进行无限扩展。分层领域单元适用于由很大的组织构建的很大的产 品线。其主要缺点就是模型可能过大，因而降低了组织对新需要的响应性。
14.6小 结
本章讨论了基于构架的幵发模式，即软件产品线。由于越来越多的组织发现采用产品 I线可以在成本、进度和质量方面实现数量级的改进，因此该方法日益受到宵睐„
然而，就像所有技术一样，该技术还有很多方面是未知的。从构架方面考虑，关键就是确定并管理共性和变化之处，但同时也必须解决非技术方面的问题.包括组织如何釆用该模型.如何安排组织的结构以及如何维持其外部接口。
14.7可进一步参阅的文献
[Anastasopoulos 00]给出了一个很不错的可变性技巧列表》[Jacobson 97]和[Svahnbeig 00]也列出了这些技巧
[Clements 02a]对软件产品线进行了综合讨论。它给出了大量的案例分析.并讨论了 软件产品线在实际中的应用。
[Bosch 006]讨论了组织模型。
[WeissOO]讨论了 FAST过程。[America00]对飞利浦公司的示例进行了讨论。最后， GM Powertrain 示例取自[Bass 00]。
14.8讨论题
(1)假定家公司使用一大组公共资产构建了 2个类似的系统.包括构架。很明显 这两个系统形成了 •个产品线。如果它们仅共享了一个构架伹没有共亨元素，它们是否还 构成产品线？假定它们仅共享了 -个元素，假定它们共享的只是编程语言运行库，假定它 们共享的资产是由幵发人员组成的小组：那么.它们是否仍构成一个产品线？