25.架构和软件产品线

25 Architecture and Software Product Lines架构和软件产品线

Coming together is a beginning. Keeping together is progress. Working together is success.
—Henry Ford

软件架构通常是由高级人才进行的重大时间和精力投入。 因此，很自然地希望通过在多个系统之间重用架构来最大化此投资的回报。

在实践中有很多方式发生这种情况。 我们在第13章中讨论的模式是朝这个方向迈出的一大步。 使用模式会重用一整套架构决策（尽管不是完整的架构）。 严格来说，每次对系统进行更改时，您都在重用其架构（或者您不必更改其架构的任何部分）。

本章展示了在一系列相关系统中重用软件架构（以及许多其他资产）的另一种方法，以及这样做的好处。 许多软件生产组织倾向于生产彼此相似的系统或产品。 这是在这些类似产品之间重用架构的机会。 这些软件产品线简化了一系列类似系统的新成员的创建。

事实证明，这种重用带来了很多好处，包括降低了建造成本，提高了质量并大大缩短了上市时间。 这就是软件产品线方法进行系统构建的诱惑。

软件工程学院将软件产品线定义为“一组软件密集型系统，它们共享一组共同的、受管的功能，这些功能可以满足特定细分市场或任务的特定需求，并且是通过使用一组通用的核心资产开发而成的。 规定的方式。”

愿景是基于共同的体系结构和构成该架构的软件元素，提供一组可重复使用的资产（称为核心资产）。 核心资产还包括设计及其文档，用户手册，项目管理工件（例如预算和进度表），软件测试计划和测试用例等。

产品线方法之所以行之有效，是因为核心资产是专门为支持同一系列产品的多个成员而构建的。 因此，与为组织产品组合中的每个新产品或系统重新发明这些软件资产相比，重新使用它们更快，更便宜。 核心资产（包括架构）通常设计有内置的变更点，这些地方可以以预先计划的方式快速定制它们。

核心资产到位后，系统构建就成为

• 访问核心资产库中的适当资产
• 行使变化点以根据要构建的系统的要求对其进行配置
• 组装该系统

在理想情况下，这可以自动完成。 如果根本需要为单个产品开发的其他软件，则占全部软件的一小部分。 集成和测试取代了设计和编码成为主要活动。

产品线在制造业中并不是什么新鲜事物。 许多历史学家将这一概念追溯到伊利·惠特尼（Eli Whitney）在1800年代初使用可互换零件制造步枪的过程中，但也存在较早的例子。 如今，制造业中有数百个示例：想想通用汽车、丰田、波音、空中客车、戴尔，甚至麦当劳等公司的产品，以及每个公司生产的类似产品组合。 每个公司都以不同的方式利用共性。 例如，波音公司同时开发了757和767，这两架完全不同的飞机的零件清单重叠了大约60％。

成功的软件产品线所带来的成本、上市时间和生产率的提高令人叹为观止。 考虑：

• 诺基亚将软件产品线方法归功于其灵活性，使其每年可以将十几部手机推向市场，而不是以前可以管理的三款左右，而这些功能都具有前所未有的功能。
• 康明斯公司能够将生产柴油机软件所需的时间从大约一年减少到大约一周。
• 与在软件产品线工程出现之前制造的软件相比，惠普使用四分之一的员工，三分之一的时间来构建产品，缺陷的数量则为原来的二十五分之一。
• 德意志银行估计，通过将全球交易和结算软件构建为产品线，每年可节省400万美元。
• 飞利浦报告称，通过采用产品线方法，可以减少高端电视产品组合中的故障。 产品多样性曾经是其架构师关注的三大问题之一。 现在，它甚至根本没有列出关注点； 产品线方法已使软件开发脱离了关键路径-软件不再确定产品的交付日期。
• 美国国家侦察局报告说，凭借其委托的卫星地面控制系统产品线，第一款产品要求开发人员的预期数量为预期数量的10％，而缺陷数量则为预期数量的十分之一。
• 在飞利浦的医疗系统产品线中，软件产品线方法已将软件缺陷和上市时间减少了一半以上。

创建成功的产品线取决于涉及软件工程，技术管理和组织管理的协调战略。 因为这是一本有关软件架构的书，所以我们专注于软件产品线的架构方面，但是为了使组织成功创建产品线，所有方面都必须协同工作。

黑暗中可能有光明

软件产品线范例是一种强大的方法，可以利用对架构（和其他核心资产）的投资进入一系列相关系统，从而看到上市时间，质量和生产率的数量级改进。 这些结果是可能的，并且已经在许多不同领域的大小公司证明了。 效果是真实的。 此外，来自许多来源和公司的数据以惊人的一致性证实，要使投资获得回报，组织仅需要构建三种产品。 这是我们期望在产品线中拥有的最低数量。

但是其他结果也是可能的，并且在尝试采用这种方法时不会出现惊人的崩溃和烧毁。 与任何技术一样，产品线实践也需要对其采用进行认真考虑，并且必须考虑公司的历史，状况和文化。 可能导致产品线故障的因素包括：

• 缺乏冠军，缺乏足够的控制权和可见度
• 管理层未能提供持续和坚定的支持
• 中层管理人员不愿放弃对项目的专制控制
• 无法清楚地确定采用产品线方法的业务目标
• 在遇到困难的第一个迹象时放弃方法
• 未能对方法进行适当的培训，并且未能充分解释或证明变更的合理性
• 在管理架构的变更点时缺乏纪律性
• 对产品线的范围过宽或过窄
• 缺乏产品线工具来帮助管理和执行变化点

幸运的是，有一些克服这些因素的策略。 一个好的策略是启动一个小而引人注目的试点项目，以证明软件产品线的定量收益。 怀疑论者开展业务时，那些愿意尝试新事物的人可以配备飞行员。 它可以解决流程问题，明确角色和职责，并通常在解决方案过渡到更广泛的环境之前解决错误。

—PCC

25.1 An Example of Product Line Variability 产品线可变性的一个例子

[TODO]

25.2 What Makes a Software Product Line Work? 软件产品线的工作原理是什么？

[TODO]

25.3 Product Line Scope 产品线范围

[TODO]

25.4 The Quality Attribute of Variability 可变性的质量属性

[TODO]

25.5 The Role of a Product Line Architecture 产品线架构的作用

[TODO]

25.6 Variation Mechanisms 差异化机制

[TODO]

25.7 Evaluating a Product Line Architecture 评估产品线架构

[TODO]

25.8 Key Software Product Line Issues 关键软件产品线问题

[TODO]

25.9 Summary 小结

[TODO]

25.10 For Further Reading 进一步阅读

[TODO]

25.11 Discussion Questions 问题讨论

[TODO]