第IV部分从一个系统到多个系统

Posted 2020-11-24 mongotea

 

 

第iv部分继续讲述构架商业周期。第I?3部分讲述了构架的质量属性、编档、设计、 重构、评估等内容。第IV部分论述的重点是根据该构架构造多个系统.它讨论了系统产品 线.并给出了相关示例。这一部分是从如下5个方面进行论述的：产品线所采用的技术： 构建海军舰艇发射控制系统的产品线的•家公司；行业范围内的构架：生产基于行业范围内的构架的产品的-.家公司：以及-家用商业组件构建系统的组织。

 

软件产品线具有重用任何资产的潜力，从需求到测试计划到人员。这种重用的关键是构架。第14 章重点阐述了产品线构架的定义和幵发。构架和组织之间存在着密切关系， 对此您现在应该很淸楚了，因此，我们对组织问题进行了讨论。

 

第15章是我们给出的第个案例分析。该案例讲述的是瑞典的CelsiusTech公司为海 军视艇发射控制系统构造产品线的故事。在此我们讨论了构架，但也较为详细地讨论了组织在采用产品线后，其结构和文化发生了怎样的变化。

 

CelsiusTech是一家为多个产品构建构架的组织。然而，行业内也有支持构架。例如， Jsva 2 Enterprise Edition/Enterprise JavaBeans (J2EE/EJB)就进针对基于 Web 的信息系统设计的构架规范，它是许多公司所开发的产品的基础构架•>第丨6章讨论了 J2EE/EJB的构架 决策和在这些决策中可能进行的权衡。

 

tomedius是一家构建基于J2EE/EJB的产品的公司，它开发面向一线工人（如维护技 师> 的解决方案，这些人不能來在台式机前，很少使用便携式电脑，相反’他们依赖于各 移动平台。lnmedius如何根据无线技术、可穿戴计算机和便携计算机设计解决方案是第 17韋的主题《

 

I第丨8章讨论了当给出-•个构架和一些商业组件时如何构造系统,，本祭将讨论是否还 漼要设计和构建什么。

 

 

最后，我们在第19窣预测了软件构架的未来。

 

第14章 软件产品线：重用构架资产

本章讲述的就足在相关系统家族中，在经过规划的前提下，明确地重用软件构架。当 组织开发多个类似的系统并重用同-构架（以及与该构架相关的元素）时，它可以获得极 大的优势.包括构造成本的降低和上市时间的缩短。这就是软件产品线的魅力之所在。我 们将其定义为：

 

一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足了某个特定市场 或任务的具体需要，是以规定的方式用公共的核心资产集开发出来的.

 

构想就逛一组可重用资产，它包括一个基本的构架以及填充该构架的公共（大概是可剪裁的）元素。它还包括设计方案及其文档、用户手册、项目管理制品（如预算和进度）、 软件测试计划和测试用例。正如我们将要看到的一样，实现这•构想主要依赖于为产品线确定正确的范围。

 

成功地建立了产品线后，将每个可重用的资产保存在“核心资产库”中，因为可以把 它应用到多个系统中，而且蜇用资产要比重新开发划算。理想情况下.核心资产中设计了

变化点，也就是可以按预先计划的方式快速剪裁的地方。在一个成功的产品线中.系统构 建就变成了从资产库中获取适当的资产，根据对当前所构建系统的要求对其进行剪裁，然 后组装该系统。为单个产品幵发的任何软件.如果的确需要的话，所花费的费用应低于总 体软件成本的20%。集成和测试代替了作为主要活动的设计和编码。

 

当然，产品线在制造方面没有什么新鲜之处。许多历史学家认为该概念来源于Eli Whitney在19世纪80年代初使用可互换的部件来制造步枪，但比这更早的例子也有。现 在，正如福特、戴尔甚至麦当劳一样.波音公司也有了一个产品线。每家公司都用不同的 方式充分利用了共性。例如，波音公司先后开发生产了 757和767运输机，这两架有很大 不同的飞机的部件大约有60°/。是一样的。

 

基于产品间共性的“软件”产品线代表了软件工程中•个创新的、不断发展的概念。 每个客户都有自己的需求.这要求厂商所生产的部件具有灵活性。软件产品线简化了针对 特定的客户或客户群所构建的系统的创建。

 

成功采用产品线所带来的成本降低、上市时间的缩短和生产效率的提商是惊人的.下 面给出几个这方面的示例：

 

•    采用了产品线后，诺基亚生产的_模型从以前的每年4个提高到了现在的25? 30个，

 

•    采用了产品线后，Cummins公司能够把生产针对柴油机的软件的时间从大约1年 减少为大约1周.

 

•    采用了产品线后.摩托罗拉公司生产单向寻呼机产品家族的效率提高了 400%.

 

•    采用产品线后，惠普公司的打印机系统产品家族的上市时间减少至以前的1/7，生产效率提高了 6倍.

 

•    借助于它所委托开发的卫星地面控制系统家族.美園国际侦查署报告说它幵发第

 

个产品所黹要的人员仅为预计人数的10%.并且缺陷减少了 90%。

 

创建■个成功的产品线取决于软件工程、技术管理和组织管理的协调策略。因为这是 本关于软件构架的书籍，因此我们重点讨论软件工程的软件构架方面.但组织要想成功 地创建•个产品线，所有这些方面都必须能够协同工作。

 

14.2软件产品线有效的原因

 

软件产品线的本质是在生产产品家族时，以一种规范的、策略性的方法重用资产。厂 商和开发人员认为，产品线之所以如此有效，是因为可以通过重用充分利用产品的共性， 从而实现生产的经济性。可以重用的范围很广.包括：

 

 

•    需求。大多数需求与早期开发的系统的霈求都是相同的，因此可以进行重用，从 而不用再进行需求分析。

 

•    构架设计-在设计软件系统的构架时，需耍组织中最聪明能干的工程师投入大量的时间。我们己经看到.确定了构架后，很大程度上已经允许或排除了系统的质 里目标（性能、可靠性、可修改性，等等）。如果构架不合适，那么，系统开发 肯定不会成功。然而，对于新产品的开发来说，可以通过重用构架免去这一重要的设计步骤，因此不需耍再電复。

 

•    元素。软件元素在单个产品中是适用的。一般只是代码的重用，元素重用包括重用最初的设计工作（这通常是很困难的）。捕获并重用设计中的可取之处，避免

 

(并且不要重复）设计失畋的地方。这包括元素的接口、其文档、测试计划和规 程以及用来预测或度量其行为的任何模型（如性能模型）的设计。一个可重用的 元索集就是系统的用户接口，这代表了很多关键的设计决策。

 

•    建模和分析。性能分析、可调度性分析、分布式系统问题（如i正明没有死锁）、 把进程分配给处理器、容错方案和网络负载策略都可以在产品中重用。 CelsiusTech (将在第15审讨论‘报告说在采用产品线后，与其所构建的实时分 布式系统相关的•个令人头疼的主要问题基本上解决了。当采用产品线开发个 新产品时，它非常确信己经解决了时间问题，并且消除了与分布式计算相关的错 误（同步、网络负载和死锁)。

 

•    测试。采用产品线开发后.报告和修复问题所需要的测试计划、测试过程、测试 用例、测试数据、测试工具和沟通渠道都己经存在了。

 

•    项目规划。因为我们可以利用经验对未来进行预测.所以预算和进度安排更加可 以预测..不需要每次都建立工作分解结构。可以很轻松地确定小组、小组规模和 小组组成。

 

•    过程、方法和工具。配置控制规程和实用程序、文档计划和批准过程、工具环境、 系统生成和分布规程、编码标准和其他许多日常的工程设计支持活动都可以在产 品中重用。总体软件开发过程已经就绪，而且以前一直在使用。

 

•    人员。因为所开发的应用具有共性，因此可以根据需要在项目之间调动人员。这 样.这些人员的专业技能就可运用于整个系列的各个产品的开发中。

 

•    样本系统。将所部署的产品作为高质量的演示原型以及性能、安全性、保密性和 可靠性的高质量的工程设计原型。

 

•    缺陷消除。采用产品线方法可以提高质量。因为每一个新系统都受益于己采用该 产品线开发的系统中的缺陷消除活动。幵发人员和客户的自信心随着每个新实例 的开发而提高。系统越复杂，-次解决整个产品家族的令人烦恼的性能、分布、 可雅性和艽他工程设计问题的回报就越高。

 

软件产品线依赖重用，但正如本章开头所说的那样.在软件工程中.重用已有很长的 历史，怛说不上辉煌，重用所得到的回报几乎总是达不到所承诺的好处。导致这种失敗的 一个原因就是直到现在仍把重用建立在“如果你建好重用库，就能获得产品线”这一思想 的基础上.可重用库中存储了以前项目中的元素，我们期望开发人员在对新元素进行编码 前会检查该可電用库。儿乎可以根据该模型开发出任何产品。如果这个库中的信息太少’ 幵发人员就找不到任何有用的东西，最后放弃寻找；如果这个库中的内容太过丰富’就很 难找到所黹要的内容。如果元素太小，与其从库中找到这些元素并进行所需要的修改，还 不如重新编写这些因素来得容易；如果元素太大，就很难准确确定这些元素的详细功能，这在任何情况下都不太可能刚好满足新应用的需要。在大多数重用库中，谱系最多只是模 糊的。开发人员不能准确确定元素的功能、其可靠性以及在什么条件下对该元素进行了测 试-在新应用需要的质最属性和库中的元素所提供的质量属性之间，几乎从来没有—个完 全匹配。

 

在任何情况下，这些元素都有可能并不适合新系统的开发人员所使用的构架模型。即 使某个元素功能正常，具有恰当的质量属性，但是否是所需要的那种构架元素（如果需要 的是对象，找到的可能是进程）？它是否具有适当的交互协议？它能否遵守新应用的错误 处理或故障切换策略？诸如此类的问题都值得怀疑。

 

软件产品线通过为重用建立一个非常严格的上下文来使其发挥作用。对构架进行定 义；确定了功能；了解了质量属性。只有在构建时就考虑到要在该产品线中重用的元素才 能放到重用库中（产品线中把重用库叫做核心资产库〉。产品线依赖战略性的或经过规划的重用而非机会主义重用来发挥作用。

 

14.3确定范围

 

产品线的范围定义了哪些系统属于该产品线，哪些系统不属于该产品线。委婉点说. 产品线的范围就是关于哪些系统是组织愿意作为其产品线的一部分开发，哪些系统组织不愿意作为其产品线的一部分开发的陈述。定义产品线的范围就像是在所有可能的系统上画一个圆环图。如图14.1所示。圆环图的中心代表了组织能够构建和将会构建的系统，因为 这些系统在其产品线能力范围之内。圆环图外部的系统不在产品线的范围内，它们超出了 产品线的能力范围。可以采用产品线开发圆环上的系统，但需要做•些工作，并且需要在 出现具体情况时进行处理。例如，在办公自动化系统的产品线中，会议室调度程序在此产 品线范闱内.而飞行模拟器则不属于此产品线。如果用一个合理的时间进行开发，并且进 行此项开发有战略上的原因的话（如将来可能有客户需要类似的产品），则个专用的内 联网搜索引擎可能也在此产品线范围内。

产品线范围l内的为白色：产品线范围外的为有斑点的区域：需要在出现具体情况时进行处理的区域为 黑色

 

该范围代表了组织对在可预测的将来.将会开发什么产品的最佳预测。组织中确定产品线范围的人有：战略规划人员、市场营销人员、对类似系统（现有系统和正在设计的系 统）进行分类的领域分析人员以及技术专家。

 

产品线的范围关系到产品线的成功与否。如果确定的范围太小（其中的产品只有少量的特性不同），则不多的产品数最会导致开发投资得不到回报。如果确定的范围太大（产 品的种类和特性都有很多不同)，则根据核心资产库开发单个产品所需要做的工作就会太 多.从而导致无法实现很大的节约。可以在最初确定产品线的过程中对产品线的范围进行求精，也可以在适当的时候对产品线进行求精，这取决于产品线所采用的策略（参见14.5.1 节)。

 

确定范围中的问题不在于发现共性---个有创造性的设计师可以发现任何两个系

 

统之间的共同点——而在于发现可以充分利用的共性，以极大地降低组织要构建系统的构 造成本。

 

在确定产品线的范围时，不要仅考虑所构建的系统。市场划分和所假定的客户交互的 类型都可以帮助确定产品线的范围。例如.飞利铺是荷兰-家消费类电了-产品的制造商， 对于家用视频电子系统和数字视频通信系统，它采用了两条不同的产品线。视频是共有的 线程，但一个是大众市场，该市场的客户基本上不具备视频方面的知识：另--个是一个小 得多的市场（根据客户的数量)，该市场的客户具备很多视频方面的知识。所开发的产品 反映了客户对视频知识了解程度的假设，以及毎个客户所受到的关注的多寡。认识到这些差别后，飞利浦公司为这两个市场开发了两个产品线。

 

范围较小的产品线提供了构建专用工具，以支持新产品规范的机会，例如：

 

• FAST是•个产品线开发过程，它基于开发一个特定于领域的语言和相关的编译 器。编译器足•种核心资产。当用特定于领域的语言捕获到了产品变化时，通过编译器生成的代码的运行时库就成为了--种额外的核心资产。

 

•    GM Powertrain根据保存在数据库中的合同，利用产品线生产出了产品。每个元素都有定义良好的接口以及可能的变化点。工具根据所期望的特性对数据库进行 搜索，并装配该产品。

 

范围较大的产品线很可能会开发为框架或服务的集合，例如：

 

•汽车供应商的导航系统的产品线要适合汽车制造商的需要，但每个汽车制造商都 坚持使用自己的用户接口和特性集。供应商把该构架设计为框架的集合。每个产 品的幵发都由构造用户接口和针对专门的特性进行的框架实例化组成。

 

•    Luther系统（参见第17章）是一个在J2EE (个框架）上构造的产品线。每个 产品的开发都由构建用户接口和实现一些应用支持模块组成。

 

产品线方法的利弊

软件产品线模式是在一个相关系统家族中充分利用构架（和其他核心资产）投资的强大的方法，它可以在上市时间.质量和工作效率方面实现数量级的改进.

 

这些结果是可能的.已经被许多不同领域的各种规糢的公司证明.所带来的影响是实 实在在的-更进一步地说，来自许多佶息源和公司的教据具有惊人的一致性，它们均证实 组织只需要构建3种产品，就可以使投资获得回报，无论如何，这是我们所能希望在产品 线中构建的最少产品教量.

 

然而，必须指出其他结果也是有可能出现的.当试图采用该方法时，有可能会产生非 常不好的结果.与任何新技术一样’在采用产品线方法时需要进行深思熟虑，而且还必須 考虑公司的历史、状况和文化.

 

以下因素都可能会导致产品线失敗：

•在具有足够控制和管理权力的位置缺乏倡导者 

•管理层未能持续提供坚定的支持 

•中层管理人员不愿放弃对项目的独有控制 

•未能明确采用产品线方法的商业目标 

•遇到了一点困难就放弃了该方法

•未能就产品线方法对员工进行充分的培训，未能充分解释变化或进行变化的理由 

 

幸运的是，对于上述大多数问题，都可以采用某些策略加以解决.一个好的策略就是 启动一个很小但能充分说明问題的试验項目，以说明软件产品线的定量优势.可以让郅些 很愿意尝试新事物的人参与此项目的工作.让那些对产品线持怀疑态度的人继续做自己的

工作.通过该试验项目可以解决过程问题，澄清角色和责任，并且一般可以在广泛采用产 品线方法前解决所存在的错误。

 

Cummins公司（一个非常成功的软件产品线的承办商，已编入[Clements 02b] >的Joe Gahimer讲述了这样一个故事：其所在组织的两个产品的所有者都宣称自己产品的特性是 独一无二的.他们认为尾轴调节器和巡航控制调节器没有丝毫相似之处.它们都控制速度, 但二者之间的相似性仅此而已。核心资产小组耐心地与双方进行沟通，以捕获两个应用的 细节，最后证明这两个特性不仅相似，而且实际在功能上是相同的，它们都以一个数字常 量为模.

 

在采用产品线方法时，坚定不移地执行该方法可以得到回报.，实际上对此处列举的 大多数失敗的原因来说，这是最好的补救措施„ 一个最关鍵的因素就是组织中要有一位倡 导采用产品线方法的人（根据定义)，他坚持采用产品线方法，说服持怀疑态度的人，并 慢慢地灌输战胜困难的决心.