构建符合上述特征要求的软件系统产品线，对以往的系统开发确实是一个严峻的挑战。 如果仅仅使用传统的系统开发方式，则很难满足产品线开发的要求。如图8-1所示，如果 —个公司决定将其现有的软件系统产品进行产品线化工作，则需要在六个主要方面采取相应的变革，我们称之为产品线架构变革过程模型，简称为PLAEM模型（Product Line Architecture Evolution Model)。
.png)
①需求分析阶段：为适应软件系统产品家族所共有的特征和各异的特性，除了需要进 行传统意义上的需求收集、整理、分析外，还需要进行软件产品线的需求共性/可变性分析， 共性/可变性分析是产品线所独有的一种需求分析，分析的最终结果将严重影响后续产品线 架构的构建。
②系统架构阶段：传统意义上的架构构建，往往是为单个系统构建其内部组成结构及 结构间的关联关系。而软件系统产品线化的工作，需要首先制定覆盖各个系统的整体产品 线架构。即构建高于单个产品架构之上的产品线架构体系。产品线上各个系统产品的架构 构建将受制于产品线架构的约束和影响。换句话讲，每个产品只是产品线架构的一个实现 或实例（Instance)而已。
③构件设计阶段：传统设计进入构件级时，主要的精力是聚焦于构件的功能设计、接 口定义等具体业务功能及构件质量相关的方面上。但是，产品线设计进入构件级时，其主要任务是定义那些产品线中各个产品可以共用的功能及接口，而非把主要精力放在具体某 个产品的特定功能要求或质量要求上。即产品线要求构件级设计聚焦于能代表产品共性的 构件等这样的产品线核心资产设计上。
④测试及配置管理：产品线测试及配置管理在很大程度上所依赖的传统测试和配置管 理方法的应用范围会随着产品线的特定额外工作（构建产品线架构和产品线核心构件）而 扩大和变化。传统单个产品的测试及配置管理，必须适应产品线开发所产出的产品线核心 资产及产品线内各个产品并行开发工作这样的全新开发方式。
⑤产品线演化阶段：产品线架构及产品线核心构件的演化所带来的相应的、必须应对 的动作，对整个产品线及产品线内各个产品具有非常明显的影响。这一点，需要对传统开 发方式这种为单个产品开发所利用的模式进行改进。
⑥技术及管理因素：为了适应产品线开发这种全新的系统开发模式，一个公司必须在 公司级的技术管理及组织管理机制方面做出很大程度上的变化。否则，一个公司无法从技 术管理和运营管理上满足产品线这种齐头并进的系统研发方式。
产品线开发的模式，势必会造就分布式的工作、并行的开发和发布、复杂的变更要求、 大量的配置信息、复杂和交织的研发流程等多种前所未有的困难。如果一个公司不能解决 上述这六个最重要方面的问题，必然会导致系统研发的紊乱，这将明显违背当初希望大量 复用现有资产的良好初衷。
如果从公司范围内的流程的角度上来看，一个产品线及其成员产品的构建过程基本上 可以由下述四个重要的流程阶段所组成：产品线计划及需求分析、产品线架构及开发、产 品开发、产品线架构演化。每个阶段所执行的活动，在很大程度上与传统的系统产品开发 有着明显的区别，详细请参考图8-2:
由于本书不是一本讨论商业或流程问题的书，所以我们将把产品线研发的焦点聚集到 产品线需求分析、产品线架构构建、产品线架构演化的应对及一些不能忽视的管理因素 上，并做进一步深入探讨。需要说明的是，一个公司成功演化为采用产品线的方式进行研发，商业方面的配合工作（例如商业市场计划、财务预算等）是绝对不能忽视的重要 面。
.png)
8.2共性和可变性分析
产品线的共性分析（CommonaHty Analysis)和可变性分析（Variability Analysis)是
为了正确构建产品线架构的极为重要的一个准备步骤。分析的结果会严重影响后续的设计 和实施工作。这是因为共性和可变性分析会从下述方面回答产品线架构和设计人员最为关 心的问题：
•共性和可变性分析，会在产品线的应用领域内界定一些公共词汇，从而为以后的分 析及架构和设计实施莫定一个公共的沟通基础。
•系统化的分析，帮助界定了一个产品家族可能的范围。例如：产品家族会包括那些 成员产品。
•分析的结果，最终严格确定了产品家族中每个成员所具有的相同的功能或特性，这 就是产品线的共性部分。
•精确定义产品家族每个成员所具有的独特的功能或特性。这可以包括使用环境、组 成结构、功能行为、控制流程和逻辑的各异性等，这组成了产品线的可变性部分。
*产品线中各个产品的各异功能或特征的变化范围，需要严格定义，这将最终定义成 为一个变化区间。
通常，在产品线架构构建前，我们需要非常清晰地界定产品线的共性和可变性。从产 品线架构工作的角度来看’共性分析确保了产品线架构存在的意义并陚予了架构的长久生 命力，而可变性分析确保了产品线架构的灵活性并赋予了架构在使用时的适应能力。
1.产品线共性分析
其实，产品线的共性分析（Commonality analysis)就是以由粗至细的方式，逐渐分
解细化产品线中未来可能的成员产品所具有的共同点，并最终以结构化的方式进行汇总。 这些分解出来的共同点，在后续的架构构建中，会经过架构和设计人员的精心组织，成为 组成产品线架构的基础核心内容。
作为共性分析的第一步也是最为关键的一步，就是需要我们理解和逐步淸晰应用领域， 然后界定产品线范围的过程。举例来讲，经过了产品线应用领域的逐步分析后，我们最 终界定了产品线的范围，并给出了类似这样一个定义：“未来产品线中的产品，都是一些 独立的软硬件结合的系统。这些系统主要是用来进行公共图书馆的管理工作，这包括g 书査询、图书借阅、图书返还、图书收藏管理等7这样一个产品线共性的描述，其实界 定了我们的产品线范围既不是一个机场旅客行李处理系统，也不是一个电信程控交换机的产品线！
产品线的应用范围界定后，我们需要对产品线范围这样粗线条的共性进行深入的细化 工作，这可以包括：
分析产品线的应用领域，识别在其结构方面所存在的共性方面，例如：每个公共图 书馆管理系统都会由一些相同的子系统组成，这包括图书借阅及返还子系统、图书 馆藏管理子系统、图书借阅人权限管理子系统、图书捐赠人管理子系统等。
•在应用领域内，对所具有的相同行为或活动方面进行分析，例如：每个公共图书馆 在返还借阅的图书时，都会检查借阅人是否超过了规定的还书时间限制。如果超时， 则需要进行一定数额的罚款。
分析应用领域所使用的控制流程的共性部分，例如：每个图书馆，都会在给借阅人 提供其所借阅要求的书藉和媒质前，先会检查核实借阅人的借阅限制要求（例如有 些特定的影像资料可能只有少數权限较高的人才有权借阅），然后再提供图书及媒 质借阅的服务。
•分析产品线中的系统产品运行环境的共性部分’例如：操作系统、数据库、界面 等。
经过上述这样的共性细化分析’对产品线中各成员产品在其结构、行为、控制、环境 方面的共同点进行了识别和汇总，从而帮助架构和设计人员识别未来产品线架构中那些要 求固定不变的、并被各产品成员所共享的核心子系统、功能构件及其相应的功能和协作机 制。这些正是一个产品线架构所应该具备的重要核心资产。
2.产品线可变性分析
可以看出’产品线共性分析的直接结果，导致了架构和设计人员会将这些结果转化为 支撑产品线架构的脊梁。共性分析的好坏，对产品线架构的生命力有着震撼性的影响。那 么，为什么除了共性分析外，还需要进行可变性分析？什么是一个产品线的可变性分析？
其实，产品线可变性分析（Variabil丨tyAnalysis)事实上经常与共性分析是相对应的,
即可变性分析一般都是基于共性分析结果之上的分析工作。其结果会导致架构和设计人员 对产品家族各成员产品之间的相异特征，能够进行非常精准的差异范围定义。这样，可以 在很大程度上清晰地界定产品线中各产品的开发需求。
与共性分析相似，可变性分析也是按照由粗至细的方式，逐渐分解细化产品线中未来 成员产品所具有的各异性，并最终以结构化的方式进行汇总。这些分解出来的各异特征， 会帮助精确界定产品线范围，同时也会帮助界定产品线架构必须应对的范围变化。
其实，可变性分析是产品线共性/可变性分析中最富有挑战、最有意思的一部分。在实 际工作中，或许我们不知道进行可变性分析最先应该从哪里下手，因为一个产品线中的可 变因素实在是太多了。
经过一系列的实践摸索，我们往往可以发现，一个可变性经常是基于一个或一些共性 的基础之上。一般没有哪种可变性与产品线共性没有关系。例如：如果我们正在进行一个 空中交通管制产品线行为和活动方面的共性分析时，会发现所有的成员产品在相同的背景 和约束条件下，都需要一个航班调度的功能，这明显成为该产品线的一个共性部分。当清 晰地识别和界定一个产品线的共性后，也是触发我们进行可变性分析的时刻，因为从航空 管制的领域经验和知识来看，不同的管制系统所使用的航班调度算法并不相同。这明显会 成为未来成员产品的各异之处。所以当你界定了某个产品线共性之时，就是你开始进行可 变性分析的时刻！
为了能够系统全面地进行产品线可变性的深入分析工作，一般从下述方面进行逐步分
析：
•从应用领域上分析产品线中的产品成员，在其结构方面所存在的各异方面，例如： 有些公共图书馆在物理上位于某个或几个建筑物内，有些电子化图书馆是由图书馆 网络形成的虚拟图书馆；同时，不同图书馆的馆藏图书或媒质也不尽相同。
产品线中的各产品成员，所具有的各异的行为或活动是不同的，例如：每个公共图 书馆，其图书超过规定还书的时间限制、罚款政策、罚款數额等就各不相同。
分析产品线中各产品成员所使用的控制流程的各异部分，例如：为了有效地进行图 书借阅的监督、控制和管理，有些图书馆会利用系统记录每次借阅发生的时间、借 阅人、还书时间等借阅信息。这样可以方便地跟踪借阅过程，形成有效的管理记录。 但是有些图书馆并不会记录和保留这样的信息。
^分析产品线中各产品成员运行环境的各异部分，例如：操作系统、数据库、界面等。
只有进行了有效细致的可变性分析，才能很淸晰地界定一个产品家族中各个产品的区 别。这样的分析结果，必然会使架构和设计人员能够精确地构建一个产品线架构。这一方 面确保了该产品线架构足以灵活地应对那些己经分辨出的可变因素；更为重要的一方面， 可以确保产品线架构中那些共性的、为所有成员系统共用的核心结构和功能不会由于没有 进行可变性分析，而在未来受到严峻的挑战，从而避免了震撼性的修改。
3.共性/可变性分析流程
产品线共性和可变性分析，一般都遵照如图8-3所示的一个循环往复的迭代方式来进 行。我们可以将分析工作划分为下述几个重要的阶段：
.png)
1)识别和划分相应领域
作为共性和可变性分析的开始，首先需要将产品线所适用的应用领域进行分析、识别 和切分，最终将一个大的领域分解为合理的小规模领域或应用方面。只有这样做，才能方 便我们对每个小规模的应用领域或应用方面集中进行细致的共性和可变性分析。
这样切分应用的另外一个好处是在一定程度上帮助检验了整个产品线架构基础分割是 否合理。因为应用领域的切分，往往成为后续构建产品线架构的核心基础；而后续的共性 和可变性分析是基于应用领域切分之上的更加深入细致的分析过程，分析出来的共性和可 变性往往成为产品线架构上的核心可重用资产。
对一个应用领域的切分，基本可以从应用的功能结构上、应用所产生的行为和状态上、 应用所涉及的控制流或工作流上，以及相应的应用质量上（分布应用、并发要求、安全机 制、容错能力、应用状态一直性等）来将一个应用领域横向切分为层，再纵向切分为块， 使后续的分析尽可能细致。
2)单个领域的共性分析
当我们面对一个被切分出来的领域（例如：该领域是一个具体商业功能）时，我们需 要利用场景（Scenario)模拟的技术来逐步澄清这样一个领域的各种情况：
•该单个领域是一个实现什么目的（例如：容错）的领域。
•当该领域进行某个具体动作之前的先决/触发条件有哪些。
•触发条件出现的情况下，该领域会产生怎样的动作、行为或状态变化。
该领域既定的动作完成后，会有怎样的后续事件，从而与其他领域进行协作或交互
等。
基于场景的分析，可以帮助我们非常精准地理解该领域的具体细节。然后基于上述问 题的分析结果，我们会开始尝试回答这样一个问题：“这样一个领域所实现的功能，其相应的场景造就的具体行为，是否是产品家族中每个产品成员都是一样的？ ”如果答案是肯定 的，那么，这就可能是一个共性。否则，它可能是一个可变性。但是，我们并不能现在就 肯定地说，该领域一定就是产品线的共性。这必须伴随着后续其他领域的逐步分析，才能 最终下结论。因为各个被切分的领域之间，经常也存在着某种协作关联关系。
3)单个领域的可变性分析
从共性分析中，我们已经看到了一个非常明显的现象，基本上所有的可变性都是由某 个或某几个共性而衍生出来的，即可变性相对共性来讲是具有着伴随性的。这其实意味着， 共性分析达到一定的阶段，也就是我们开始进行可变性分析的开始。
进行可变性分析的一句至理名言是“立即记下那些你认为可能是可变性的东西丨”。这 主要因为，进行可变性分析时，有些领域或方面看似像是共性，但是你目前感觉并不那么 肯定；有时，你还会明显看出有些可变化的方面中，也存在着一定程度的共性部分。无论 怎样，当共性分析进行到-定程度时，那些可变性（例如场景分支的不同、错误处理机制的各异等）就已经自然而然地出现在你面前。这时，你可以花些时间对这样浮现出来的可 变性进行分析，不妨从如下五个方面来进行思考：
变化的粒度：这种可变性影响的范围是子系统、系统层、构件、类、服务还是算法。、
变化的类型：可变性的种类属于功能的扩展、动作的替换、性能的改进，还是功能 的剔除。
变化的频率：变化的频率是很高、一般’还是很低。
变化的时间：产品家族要求当前就进行这样的变化，还是未来某个产品、某个时刻 要求这样的变化。
变化的执行：由谁来执行这样的变化：开发人员、服务人员、系统管理人员、系统 用户，还是系统自适应。
4)将一些可变性转化为共性
分析进行到现在’我们手中已经有了一些产品线的共性和可变性分析结果。这时,
果我们仔细研究那些记录下来的可变性，就会发现这样一种现象：有些我们分辨出来的可 变性，其实是某种共性的一种非常例外的特殊情况。例如：我们进行公共图书馆管理产品 线的可变性分析时，会看到分析的结果记录了这样一个可变性虽然大多数书籍都有作者， 但是有些书没有作者。”
对于这种由于例外造成的可变性，最好的实践经验就是将其改写为共性：“每本书籍都 包含了如下信息，其中一些信息是可选的：书名、作者（0或多个作者)、绪言（可选)、 目录……”
有时，我们也会看到这样记录的可变性：“图书借阅人的种类各不相同，有的是老年人， 有的是青年人，有的是未成年人。”如果我们再仔细看看这个可变性，就会发现它符合下面 这样的特征：
•进行系统设计时，这种可变性非常容易被设定为一个静态变化的范围。
这种可变性的绑定时刻明显是在系统运行时刻。
•每个产品成员都需要在运行时应对这种静态变化的发生。
•将这种可变性变为共性更为合情合理一些。
通常，符合上述情况的可变性，都应该将其转变为产品线的共性。那么，我们的可变 性就可以改写为这样的共性图书借阅人的种类只有老年人、青年人、未成年人三种类型。”
5)可变性可变范围参数化
如果只是将分辨出来的可变性简单地记录下来，还是非常不够的。架构这种工程领域 讲的就是将一件事尽可能地量化，以便于能够定量处理。现在，我们还需要将这些收集的 可变性依次进行其可变范围的参数化工作，即我们需要分析出一个可变性是在一个怎样的 范围区间内进行变化的。这样做，在很大程度上会帮助我们理解和界定一个可变性是如何 变化的。
可变性的参数化，就是根据变化的种类，将可变性这种文字描述，转变为相应的数值 或状态等精确区间。可以以数值代表区间，来表示一个系统的容量变化范围，例如[100, 5000];也可以用文字来表述产品所使用平台的变化可能，例如：产品所使用的平台是 {Windows, Linux，AOS, Mac}；质量要求也可以成为量化的参数值，例如：产品成员的 可靠性要求{高，中，低）
从经常遇到的情况是’进行第一轮共性和可变性分析时’我们或许不能非常清晰地进行 可变性范围参数化。但是，随着若干次的反复工作，我们必须逐步将所有的可变性进行参 数化。
6)设定可变性的绑定时间
每一轮分析结束前，我们还需要完全掌握每个可变性的绑定时刻。这样做的主要原因， 是为产品线架构构建和设计人员设定一个可变性发生的时刻，以便设计人员能够应用不同 的绑定方式来应对每个可变性的发生。
可变性绑定时间的分析，首先是可以依靠如图8-4所示的两个维度来衡童每一个可变 性所发生的时间表：空间或范围维度、时间维度。
.png)
所谓空间或范围维度，是指在特定的时间，哪些可变性会发生在产品家族的哪些成 员身上。
•时间维度，主要是以时间为变化顺序，来安排未来的变化可能。
以空间和时间这样两个维度来分析和安排每个可变性，对后续的架构、设计、实施的 影响是不言而喻的。如果是现在必须应对的可变性，那就在当前的成员系统实施中实现； 如果是计划好的未来某个时刻所发生的可变性，我们的架构也必须留有可扩展的空间。
这样两维的分析，也帮助我们完全了解每个可变性的绑定时间。
•产品线范围规划期间：在该时期绑定一个可变性，也就意味着必须分析和抉择考虑 这种可变性是否可能对产品线范围引起变化。
•架构构建和设计期间：运用架构构建和详细设计所可能的手段，来应对这种可变性
的发生。
•代码编译期间：条件编译就是一个很好的绑定可变性的例子.
•系统安装部署期间：产品安装部署时，可选择灵活配置的方式来应对。
•产品运行期间：系统运行时，可根据不同的外界触发，结合自身的状态采取不同的
应对行为。
从这些可变性绑定时间上，我们就可以看出，设定一个可变性的绑定时间•在很大程 度上影响了产品线架构构建的决策。不同的绑定时间，造就了设计和技术实现上的不同。
4.共性/可变性分析实例
8.3构建软件产品线架构
一个公司，将自己的产品改造为产品线，必须经历一次痛苦的改造过程，那就是需要 进行一次产品线架构的构建工作。从纯架构理论的角度上来讲，构建一个系统的架构与构 建一个产品线的架构无论从利用的架构策略、架构风格、设计手段、使用的技术、架构的 方法和过程等方面都没有什么本质的区别。但是，由于产品线架构必须应对产品共性及可 变性这样的特殊性要求，所以使其构建过程有其独特和复杂的一面。也正是由于这种特殊性，使得产品线架构的构建与传统系统架构的构建有着不同之处。
产品线架构构建之前的共性和可变性分析，在很大程度上已经告诉产品线架构的构建 人员：在一个产品线所预期的范围里，有哪些是具有共性并可重用的，有哪些是产品线可 变的部分。这成为架构人员进行后续种种架构层面抉择时的重要输入信息。
当前，架构人员面对的是过去那些年积累下来的若干系统产品，头脑中也已经明确了 产品线所要求的共性及可变性。但是，在真正开始产品线架构构建前，架构人员还必须做 出一个架构战略层面的抉择。在做出这个抉择前，还不能真正开始架构的构建工作。那么， 架构人员要抉择什么呢？难道这样品质优秀的前期分析工作，还不足以开始进行产品线的 架构构建吗？
如果参考业界产品线构建的实践，我们就会发现，一个公司在真正构建产品线架构前， 会考虑使用下述两种方式中的一种来构建自己的产品线架构，这其实可以称得上是最具震 撼性的一个架构战略层面的抉择。
•框架风格（Framework)的产品线架构：框架风格的产品线架构，主要是指将产品 线架构构建成为类似于.NET或J2EE这样风格的框架。但是，该框架是适用于某 个具体应用领域的应用系统框架，而非.NET或J2EE这样的通用应用开发框架。 框架风格的产品线架构，首先要求在构建前进行大量精细的并且是前瞻性的产品线 范围、共性及可变性分析。这样才能保证一个产品线架构经历多年时间的检验证明 是通用、可靠的整体产品的总架构；其次，需要有非常前沿的预测经验来进行未来 演化的预测，这往往是一件非常难以做到的事情；另外’要求采用这种框架风格的 公司，在其产品服务的商业领域内有大量成熟的实践经验和领域知识。看来，框架 风格的产品线架构明显是一种重量级的产品线架构。虽然选择这种风格所付出的前 期代价很大’但是这种方式是最彻底、重用度最髙、重写的代码最少、系统产品交 付最快、系统质童最容易控制、开发人员要求最低、开发管理最容易的一种方式。 通常，喜欢采用这种方式的往往是一些老牌的大、中型公司。例如：世界著名的西 门子的“SEMATIC”框架，就是一个工业自动化控制领域中典型的框架风格的产品线架构。
•标准产品风格（Standard Product)的产品线架构：标准产品风格的产品线架构，
是指公司构建和开发一个被其他系统产品参照的标准产品。它成为了产品线架构的 核心组成部分，而其他产品的开发完全是对该标准产品的设计重构或定制化开发。 当然，这个标准产品在进行架构和设计时遵循了 “Open for evolution, but closed to modifications”这种架构和设计准则。例如：利用配置文件来修改系统参数。很明 显，标准产品风格的产品线架构是一种轻量级的产品线架构。相对框架风格的产品 线架构而言，标准产品风格的产品线架构前期的投入明显减少了。这个优点使它非 常适用于那些业务刚开始发展、行业领域经验不足、前期成熟产品不多、不可能投 入大量精力去进行分析的中小型公司。这些公司往往也需要应对多个不同客户的个 性化要求。需要明确的是，虽然这是一种投资少、见效快的产品线架构方式，但是 如果不能很好地控制标准产品中各个构件的质量（例如可扩展性、健壮性），那么 这样的产品线架构在未来的某个时刻，必定会面临严峻的挑战。
业界各公司基本上都会遵循上述的评判原则和维度，再结合公司自身的发展现状，来 选择两种风格中的一种。如果现阶段架构人员的抉择是错误的，必然会使产品开发工作在 未来的某个时刻会付出沉重的代价。
当选择了适当的产品线架构风格后，就正式进入了架构构建的时期。我们可以以两个 简单的实例，来看看不同风格的产品线架构是如何构建的。
1.框架风格（Framework)的产品线架构
H公司是一家专门从事网络设备研发制造的公司，该公司已经有了十几年的网络设备 生产经历。旗下的主要产品包括网络打印机服务器、网络CD-ROM存储服务器、网络文件 服务器、网络摄像服务器、网络扫描仪服务器等产品的研发和生产。可见，H公司已经在 自身产品所服务的领域积累了大量的经验。
随着市场的发展和技术的快速演化，H公司的产品从最早只配合和支持旧M Mainframe机的打印机服务器，开始逐渐面临需要解决IS09660这种为CD-ROM所支持 的文件格式，因此要开发网络存储设备。接着H公司又需要去应对FAT、UDF、MTF等的挑战，因为公司的业务发展己经开始要求其产品从单一的打印机服务器向其他网络设备产 品上发展。
这时H公司已经面临我们上文中反复提到的困境，如果因为某个单个变化就去开发一 个全新的产品，这显然既费时’又费力。为了应对市场和技术发展的快速变化，该公司决 定将自身的各种产品按照产品线的方式进行改造和演化。由于在其领域内的长期经验积累， 加上公司的规模已经属于中型公司，财力上也可以承受得起这样的巨变。最终，H公司选 择了代价最高，但也是受益时间最长的框架风格的产品线架构。
由于H公司产品线比较复杂，我们可以参考如图8-6所示的经过简化的产品线架构组 成结构图。
.png)
从这张产品线架构结构图上，我们可以非常清楚地看到，该网络设备公司的产品线架 构’从结构上来看其实并不像通常我们对产品线所理解的那么简单。整个产品线分成了不同层面的产品线架构：这包括最高层面的“整体产品线架构”；第二层有“网络存储服务器 产品线架构”、“网络摄像服务器产品线架构”、“网络扫描器服务器产品线架构”：底层则有 “CD-ROM服务器产品线架构”和“文件服务器产品线架构”；而最终处于该树状产品线结构的叶子位置，才会是一个个特征各异的网络产品。
因为该公司采用的产品线架构是框架风格的，所以相对应的框架出现在了产品线的各 层上，如图8-7所不。
.png)
从图8-7中可以看出，该公司的产品线架构其实就是由那些位于不同层上的框架组成 的（文件系统框架、网路协议框架、网络文件存储框架、网络摄像框架、网络扫描器框架 等)，这些框架也成为了产品线的核心可重用资产。
在这些框架当中，最为重要的一个核心框架就是位于顶端的“文件系统框架”。该框架 是整个产品线架构中最为核心的且是对各个产品共用的文件管理功能进行的抽象。其次， 从整个产品线中提炼出来的共性也促成了 “网络协议”这个框架的产生。该框架提供了文 件系统利用不同协议进行网络交互的功能，这明显是网络设备的另外一个最大的共性。
为了深入了解每个框架遵循了怎样的构建原则，我们可以来看看“文件系统框架”和 “网络协议框架”这两个主要的框架的内部结构细节，如图8-8所示。
.png)
从这两个框架的细节上可以看出，每个框架基本都使用了相同的策略来进行构建：首 先，每个框架都会再次抽象出图中顶部的那些公共部分。然后，针对不同的文件格式/文件 标准和不同的网络传输协议的各异性，提供了框架级的实现定义和支持。
我们己经很完整地看到了一个公司为自身产品服务领域所构建的产品线框架。这很明 显是一个其领域内的应用框架（而非公共开发框架)。这样的一系列框架在最大程度上满足 了产品中共性方面的抽象和重用，同时也在最大限度上完整而细致地处理了产品的各异性 要求。由于框架本身大多利用了抽象与具体实现并举的方式，这也使得框架风格的产品线 架构非常易于扩展和修改。
框架风格的产品线架构中的核心可重用资产，主要是由这些框架组成。这其实也就意 味着所有的产品都自然而然地严格受限于框架的约束。所以一个产品线架构的质量在很大 程度上决定了每个产品的质量。这其实是为什么很多公司采用这种产品线架构的另外一个 诱人的原因。因为大家都会梦想使用一种极致的架构强制约束力，来影响和控制各个产品的开发质量。框架，确实是目前一个比较理想的强制约束方式。但是，框架也是一把双刃 剑，如果产品线框架的构建质量不高，其后续的修改则会波及每个产品。这种成几何级成 长的变化，对公司产品开发而言绝对是一种灾难。所以，使用框架风格，首先必须付出痛 苦的代价，然后才能去完成大家美好的愿望。
2.标准产品风格（Standard Product)的产品线架构
L公司是一家从事竞投标管理系统产品的开发公司•该公司的主要产品是为了满足客 户在商业竞投标时进行必要的管理工作，从而在最大程度上使客户利用该公司的产品更好 地应标，并最终贏得商业机会。通常，该商业领域内的客户在使用某个竞投标管理系统时， 会普遍希望该系统能够满足以下要求：
•该系统能够详尽地搜集、记录、分析一个招标方所提出的各项产品规格要求。
•通过对标书内产品或服务规格和要求的分析，系统能够有效地帮助应投标方设计满 足要求的应标方案。
•在价格计算和控制方面，系统要能够帮助应标方去分析预计的成本及可能的营利空 间，从而以具有竞争力但不失合理利润的价格来应标。
我们来看看最后L公司创建的这个标准产品的架构结构。由于是基于Web的应用，公 司先前的产品又大多是Java编码，所以基本上沿袭了 J2EE应用的结构样式，如图8-9所示。
.png)
从8-9这张L公司标准产品的简单架构结构图上，我们能看到架构师为了应对各种未 来的变化所做出的架构层面的抉择。
•首先，架构师使用了流行的分层风格的架构。分层风格的架构在很大程度上割裂了 不同系统逻辑功能所处的位置。这样做的结果，就非常有利于一个应用分布式地部 署在不同的物理地点、不同的机器上。
•最前端是一个完全可以定制化的客户展现层。该层中如传统的J2EE展现层一样， 大量使用JSPs和JavaBeans来提供页面输入输出和报表展现。由于商业逻辑大量地被后置于其他层，造就了这个标准产品为了应对不同客户的不同页面要求时，可 以在标准JSPs页面的基础上进行修改，提供不同的页面展现。
•其次，分层的架构在很大程度上将公司先前成熟产品的功能，分割在不同的层次上， 所以标准产品的商业逻辑层上大量利用了系统配置文件和Facade等动态绑定和信 息隐藏的技术手段来最大程度地提高系统的灵活性。这样做可以针对不同客户要求 进行不同产品功能组合。
•由于是产品线架构级的标准产品，抽取出来的产品线很多共性部分被放置在了标准 产品架构的“核心基础服务层”上。例如：可以根据应用进行灵活配置的工作流引 擎、文档管理服务、来自ERP和CRM系统数据的淸洗和整理等。同时，为了方便 地使用第三方开发的服务构件，使用配置文件就可以灵活地集成在这个核心服务层 上。
•为了满足不同客户在不同数据目的地所要求进行的数据持久化操作，使用底层的数 据持久化层来进行数据同步。
•由于应用安全机制方面是一个普遍的共性要求，所以标准产品中也构建了一个提供 身份识别、资源授权的公共安全机制（图8-9中没有标出）。
基于上述的架构抉择开发出的标准产品，在很大程度上融合了历史产品的各个功能， 并将各个功能重新分配部署到不同的架构层上。同时，每个层都又适当地采用不同的设计 手段来最大限度地考虑了修改和扩展的要求。同时，将共性部分集中部署在产品的一个集 中的位置上，这将有利于核心共性资产的演化和管理。
从这个标准产品风格的架构实例上，我们看到了 “灵活性”这个字眼出现的频率很高。 事实上，构建这样一个产品线架构，与通常构建一个普通系统的区别不是很大。只是在构 建标准产品时，除了考虑其他系统质量因素外，最让架构师时常铭记于心的就是尽可能在 每个系统位置上做到最大限度的灵活。同时，在切分系统功能时能够尽量将共性的功能集 中在一起。这也就是所谓“灵活加集中” 一说的渊源。
从设计手段的角度上来讲，无论是采用框架风格的产品线架构，还是采用标准产品风 格的产品线理念，一般在进行架构构建时，由于需要解决的可变性特征的不同（例如：可 变性的绑定时刻的不同），使适应各种可变性的设计手段的不同。例如：使用动态属性 (Dynamic Attributes)的方式，就是利用了动态属性的变化可以影响系统行为这个特点， 来完成变化所要求的动作；使用传参（Parameterization)的方式，可以将发生的变化传递 到相应的目标点，从而触发后续行为的转变；使用继承（Inheritance)的方式，可以非常 方便地扩展既定的动作；有时，使用类似于Broker或Facade的一些设计模式，也可以在 很大的程度上解决变化所要求的适应动作。在实践中，我们还可以利用类似于模板、脚本、 回调、配置文件等动态绑定机制来应对各种类型的可变性。
8.4软件产品线架构的演化
如果一个公司决定采用产品线的方式来组织其各个产品的研发，那么公司就必须面对 一个与传统系统产品研发过程不一样的重要方面：产品线架构自身的演化对公司产品研发 所带来的冲击。
随着时间的推移，一个产品线架构也会随之发生明显的演化。笔者曾经与西门子前医 疗部门、世界著名的产品线架构SYNGO的总架构师、老前辈Dr Wangler探讨过，发现 SYNGO的演化过程，也是一个非常漫长、经历了很多代、缓慢而曲折的过程。即便SYNGO 这样一个非常成功并且成熟的产品线架构，目前还在准备继续向一个全新的方向演化。由 此可见，持续不断地演化也是产品线架构不可避免的一个趋势。
产品线架构的演化是一个非常复杂且难以应对的问题。在演化过程中，我们会看到市 场需求和技术的进步’会对整个产品线架构的结构组成造成巨大的冲击。有时，一个系统 功能变更的需求’也会促使我们对产品线架构中的各种构件进行变更。所有的这些演化， 也会对遵循产品线架构的各个系统产品造成直接的影响。为了应对这样的复杂演化过程， 我们可以来看看客观现实中会发生些怎样的变化，从而帮助我们分门别类地进行系统化的 应对。
1.市场需求变化的种类
市场需求的变化往往是对产品线架构造成直接影响的主要因素。那么，一般哪些种类 的市场需求会迫使我们进行产品线架构的演化呢？从图8-10中，我们可以看到现实中所发 生的种种可能性
.png)
基本上，图8-10巳经涵盖了实际工作中我们能够遇到的市场对产品线架构演化要求的 各种类型。
构建一个全新的产品线：伴随着一个公司的发展，当它拓展进入到一个相对而言是 全新的市场领域时，这会要求公司提供一系列全新的产品来服务于该市场，这往往 会导致一个全新产品线架构的诞生。
•产品家族中增加一个产品成员：除了公司目前产品家族中的成员产品之外，市场上 很多客户出现了普遍的新需求，要求在目前的产品家族中增加一个新的成员产品。
•改善当前产品家族的功能：随着市场的持续变化和发展，客户会要求我们对当前产 品家族的一个特定功能（例如从支持德语的系统界面增强为支持大多数亚洲文字的 系统界面）进行改进。
•支持新技术标准：市场上的客户已经开始普遍接纳一些新的技术标准（例如支持新 SIP协议），这也促使产品家族必须适应这种标准的快速变化。
应对市场技术环境的变化：市场上已经开始大量应用一些新的硬件平台（例如旧M 多核CPU的刀锋服务器，这种服务器的出现会严重影响产品线架构中有关并行计 算的系统架构和设计）、新的操作系统和优秀的中间件或第三方服务构件。随着技 术环境的快速变迁，往往要求我们的产品线架构能够有灵活的扩展能力，例如产品 线架构增加一个能够应对底层环境变化的层（Layer)。
提升产品家族的质量：经常会出现的一个市场需求是，要求对产品家族的非功能性 的质量要求（例如性能、安全等）进行整体提升。
在实践中，我们会发现在上述这些经常遇到的市场变化类型中，互相之间并不是分割 的。出现某一个种类的变化要求，往往会联动式地触发其他种类的变化要求。例如：在产 品家族中增加一个产品成员这样的需求，就经常会间接地要求改进当前产品线架构的功能。 有时，增加新产品成员的变化也会导致产品线必须适应一个新的技术标准的动作；与增加 新产品成员相类似，提升产品家族质量的动作，往往会要求我们为了适应市场技术环境的 变化，对产品线架构底层各种类型的硬件适应能力进行修改。
2.产品线架构演化的种类
在实际工作中，我们会发现对产品线架构的维护工作，往往也是公司非常重视的一个 技术工作方面。因为产品线架构的演化工作及其管理的质量，会严重影响产品研发的质量。 通常，一个产品线架构是由公司内专门组织中的高级技术人员来负责，这些人往往也是产 品线中各个产品的研发负责人员。
如果我们参与过产品线架构的日常维护工作，就会发现，通常的架构维护工作基本可
以分为如图8-11所示的类型。
图8-11所示的七种类型产品线架构维护工作，基本上涵盖了一个产品线架构当前和未 来可能发生的变化种类。
.png)
产品线拆分：有时由于市场的驱动，一个产品家族会很明显地朝着不同的两个或几 个方向进行演化。这时，公司会决定将一个产品家族的研发进行拆分，从而形成两 个或多个不同的产品家族。为了方便未来这些产品家族的演化，最直接和省力的做 法就是把原先的产品线架构进行拆分。这样，本来公司的一个产品线就被拆分为独 立的两个或多个产品线架构，并且各自朝着不同的方向演化。
产品线变种：同样是为了应对未来的产品朝着不同的方向演化，另外一种做法就是 以当前的产品线架构为父模板，与类似于面向对象技术中的继承一样，衍生出另外 一个子产品线架构，以方便扩展和维护，这就是所谓的产品线架构变种。在日后的 持续演化中，两个产品家族的共性部分依然由父模板的产品线架构负责维护和演 化，而个性部分由衍生的子产品线架构来完成。
增加产品线组成构件：当有新的功能要求时，需要产品家族来实现，这是现实中一 件很自然的现象。有时，一个产品线架构中没有现成的构件能够实现这样的要求， 这就要求我们在当前的产品线架构中增加新的功能构件。同时，由于构件之间存在 着协作关系，新增加的构件必须和相关其他构件建立协作关系。
升级产品线组成构件：对一个系统功能的修改也是日常维护工作中的一个重占、这 通常会导致修改产品线架构中的一个或多个构件。
切分产品线组成构件：随着产品线架构和各个产品的维护和升级，我们会发现有些 系统构件包含了太多种类的商业逻辑处理；或者有时为了增加一个功能，增加新构 件的代价又太大。所以，经常会出现将当前产品线中的某个构件切分为两个不同构 件的要求。这样既方便构件的修改和维护，同时在增加功能时也简单了许多。
产品线构件的替換：一个人有生老病死，一个产品线中的构件也有其生命周期。在 某个构件的老龄年段，设法修改它来满足新的要求，还不如重新写一个新的构件来 替换当前产品线中的退化构件，这就需要进行产品线构件的替換，
产品线构件关系重构：当我们在产品线中増建一个或几个新构件时，经常会发现 先前定义的构件间的关系不是非常合理，不能方便地帮助我们添加新构件，同时 新构件的加入也增加了新的构件关系。这时，我们会需要对原来的构件关系进行 重构。
注意：上述发生在产品线架构维护上的动作之间，也是有着千丝万缕的联系。例如： 产品线拆分或产品线变种这样的架构震撼级的动作，往往伴随了产品线新增构件、拆分以 往构件、修改构件、替换构件、构件间关系重构这样一连串动作的发生：同样，一个构件 的升级也会涉及构件间关系的变化。
3.产品线架构内构件演化的种类
在我们讨论产品线中的构件演化之前，需要说明的一点是，产品线架构中的构件，在 标准产品风格的产品线架构中往往偏重于某个具体商业逻辑的标准实现。而在框架风格的 产品线架构中，构件这个概念是由两个部分组成的：构件结构定义和若干个构件的具体实 现，如图8-12所示。
由于标准产品风格的产品线架构中的构件往往就是完整业务逻辑的实现，其演化与传 统系统演化相似，这里我们就不再讨论。而框架风格的产品线架构中的构件，其演化过程 相对特殊和复杂，基本上可以分为如图8-13所示的几种类型。
.png)
.png)
改变构件功能：改变一个构件的功能’是量级最重的产品线构件演化动作。这样做 通常是为了该构件在完成目前功能基础上，还能够支持一个崭新的功能。这种变化 首先会影响到构件结构定义层，同时构件的各个具体实现也会被波及。
新构件的实现：通常为了增加一个功能，我们可以考虑在当前的构件实现中，增加 一个新的实现，从而满足这种扩展功能的要求。
修改当前构件的实现：一个以往的构件实现，由于性能或功能方面的质量问题，需 要进行修改和优化。
替換当前构件的实现：构件的某个具体实现，也会由于其老化的原因，而被重新创 建的一个构件实现所完全替换掉。
移除构件实现中的功能：有时构件也会出现重构的情况，这时可以将构件的一个实 现当中的功能进行有选择性、合理化的移除。
增加构件实现的功能：构件重构时同样会出现把一个新的功能增加进某个当前的构 件实现中的现象。
上述这些构件的演化动作之间经常是相互关联的。例如：改变一个构件的功能，有时 也会出现修改构件某几个具体实现的要求；创建一个新的构件实现，有时又需要移除某个 实现中的功能
4.需求变化和产品线演化的关系
到现在为止，我们已经看到了实践中一个产品线架构演化的种种可能性。市场的需求 在快速变化，产品线架构会随着日常维护而不断演化，产品线中的构件也是在不断地进行 着演化。这三种维度的变化不是割裂独立进行的，而是互相牵制并互相影响的，如图8-14所示。
从图8-14我们可以看到’由于市场需求的变化，造就了产品线架构层面和产品线构件 层面都采取相应的发散式动作。例如：构建一个全新的产品线，首先会造成产品线架构层 面的产品线拆分或者产品线变种的动作，之后又会波及构件层，要求必须构建一个新的构 件实现。
正是由于产品线架构是由共性可重用部分和具体个性实现部分组合成的系统架构，市 场的一个变化就会像多米诺骨牌一样，逐层波及整个产品线的各个层面，这无疑增加了产 品线架构维护的复杂性和难度。所以，学会分门别类地总结和应对市场的变化，对保持产 品线架构这样的公司核心资产有着极其重要的意义。
.png)
8.5软件产品线的管理因素
诸多成功的实践告诉我们，应用产品线这样的方式进行一系列产品的研发，决不单单 是做好上述几个小节中所谈到的“共性/变性分析”、“构建产品线架构并开发产品线核心 构件”、“合理应对演化”等这样的几个动作就可以圆满完成的。公司管理方面的因素在整 个产品线的研发方面起着举足轻重的作用。例如：没有技术管理方面的协调，产品线架构 与产品线构件的开发会形成脱节。同样，产品线核心资产的演化也会与产品线中各个成员 产品的演化完全分离。同样，组织方面的管理也是另外一个重要方面。例如：如果我们把 公司的研发团队混杂在一起，那么研发和维护产品线架构及核心资产的人员，就会与成员 产品的研发人员是同样-组人，这样的研发组织结构势必会造成职责不淸的局面，将非常 不利于产品线的研发。
从公司管理的角度上，为了高效地为产品线提供有力的支撑，“技术管理”和“组织管 理”就成为公司必须适应产品线这种研发方式而进行变革的两个重要方面。那么，技术管 理和组织管理在产品线开发这样的模式中到底扮演了怎样的角色呢？
产品线研发方式中的技术管理，就是确保产品线研发整个过程中所发生的一系列活动， 从技术管理的角度上来衡量，完全遵照了先前规定的研发流程和各种技术要求而有序协调 地进行。通常产品线的技术管理涵盖了下面这些管理方面。
•配置管理：技术管理需要制定产品线研发时的配置管理计划，这与传统单个产品/ 系统的配置管理有着明显的区别。因为当前需要进行配置管理的，是那些被称为产 品线核心资产的架构和构件，同时还包括各个成员产品。无疑这需要一个统一的配 置管理计划来进行协调。
•自主开发/原有资产挖掘利用/外购/委托：传统单个产品/系统研发时，经常需要技术
管理基于各种分析的前提下，做出自主研发还是外购的技术决定，这同样也适用于 产品线方式的产品研发。但是，其内容扩展到了产品线核心资产和各个成员产品的 范围，并且需要分析考童的因素也急剧增加了。
•度量及跟踪：度量与跟踪在传统开发中是技术管理的一个重要方面。合适的度量和 进展状态的跟踪，能够反映出研发工作的效率和质量。产品线方式的研发也需要技 术管理制定相应的度量标准并跟踪产品线核心资产的研发以及各个产品的研发，为 管理层提供整个产品线研发的性能品质（例如成本、时间等）、研发过程是否和规 (研发流程的和规性)、研发效率（资产利用率、ROI)等的数据支持。
•流程定义和管理：无论是在产品线的需求分析阶段，还是在架构构建中的主要活动， 无论是在产品线核心资产的研发阶段，还是平滑过渡到成员产品的开发及以后的演 化应对阶段，技术管理都需要制定、维护、监督一系列流程活动的定义和执行。
•范围界定：源自市场分析和技术预测，一个产品线的范围界定也是技术管理必须组 织和执行的重要活动。
•技术计划：技术管理必须从技术的角度上制定一些技术计划，这可以包括如何开发 产品线中的各个核心构件的计划、如何维护产品线架构及其核心构件演化的计划、 开发每个成员产品的计划等。这些技术计划将告诉管理层在什么时间、以多大的成 本、进行什么活动、如何控制活动的展开、利用那些工具来完成一个什么目的的工作等重要的管理信息。
•技术风险管理：技术风险管理与传统风险管理在风险识别、风险优先级排定、风险 应对方法等方面基本一致。但是，产品线的研发使技术风险的来源、种类、处理难 度、出现时间等方面与传统的单系统研发有着明显的区别。
•工具支持：技术管理必须在产品线研发的诸多支持工具中进行选择。这包括对使用 工具的要求进行需求收集、从众多工具中进行筛选及评估、工具使用前培训、工具 使用所带来效率提升的度量、工具演化的管理等技术支持工作。
另一方面，产品线研发方式中的组织管理，为产品线方式的产品研发提供了稳定的环 境和管理支撑。通常组织管理可以在下述几个方面对产品线研发提供帮助。
•商业决策管理：商业决策将决定为了应对商业市场变化，是否要采用产品线研发方 式以及产品线中应该包含哪些市场需要的成员产品等。做出这样决策的参考依据往 往来自商业和市场分析、自身资源状况、投资风险等分析的结果。
•客户沟通管理：由于产品线方式的研发是多成员产品、多最终用户的方式，所以相 应的沟通机制必须由组织管理来建立和维护。
•采购管理：通过采购计划来安排和帮助构建产品线中的核心资产的构建及成员产品 的构建，也是组织管理必须完成的一个重要辅助任务。
•财务管理：财务管理是一个非常重要的产品线成功的保障平台。适当的财务计划可 以帮助产品线中的研发活动、培训活动、演化维护有足够的财力来完成。
•市场分析管理：对市场进行系统化的分析，从而掌握市场变化和发展的脉搏，对产 品线研发方式的成功运用有着巨大的影响，会决定产品线架构及成员产品的各种特 征：同时，市场分析的结果也是管理决策的重要输入信息。
•产品线运作管理：作为日常运作的管理，产品线运作管理将监督产品线日常的研发 和维护是否按照相应的研发和维护计划来执行，相应的沟通是否满足了沟通计划的
要求，计划的资源是否用在了规定的产品研发上等。这样的日常运作管理，其最终 目的是确保公司各项产品线生产任务，是为了按照既定的商业目的而进行，不是为 了完成什么任务而盲目地进行。
•组织规划：组织规划会结合配置管理计划、培训计划、财务计划、风险管理计划等， 有效地帮助一个公司从传统单一产品的研发模式向产品线研发模式进行转变。
•统一的风险管理：产品线研发模式的风险散布在不同的成员产品研发中，并且会出 现在不同的产品线研发阶段，所以整个公司层面统一的风险管理，将有助于通过即 时有效的沟通来识别和处理各种可能的风险。
•组织结构：公司内部为了适应产品线研发模式，需要制定相应产品线研发、生产的 组织结构，这包括规定的角色和其相应的职能。
•技术发展预测：业界未来技术的发展对公司产品线的演化具有震撼性的影响，系统 化地进行技术发展预测将有助于产品线长期的生命力。
•培训管理：无论是刚开始采用产品线模式进行产品生产的公司，还是已经采用该模 式很长时间的公司，确保培训计划的制定和执行，对产品线这种并行研发模式的应 用都非常重要。通过培训管理，确保公司人员在技术和管理这两个方面能够完全适 应产品线研发模式所带来的变化以及后续产品线演化活动的展开。
从上述技术管理和组织管理两方面需要进行的活动，我们可以看出，一个产品线的成 功不单单是技术的成功，同时也需要一个成功的管理模式来保障。
从本章探讨的各方面来看，采用产品线这种研发模式，对一个公司过去所习惯的运作 模式确实是一个非常重大和意义深远的变革。公司必须变革其需求分析的固有方式，开始 引入共性/可变性分析手段；必须建立产品线架构构建和维护的流程：必须有一个开发和维 护产品线中核心资产的团队；同时还必须有相应的技术管理和组织管理来适应新的开发模 式，可以这样说，以往的所有方面可能都需要进行一次重大的调整，否则就无法成功地应 用产品线这种复杂的生产方式。