内容


战略性重用和产品线工程

使用 IBM Rational 系统和软件工程平台

Comments

简介

由于许多产品越来越复杂和竞争压力不断加大,对工程开发效率的要求也在提高。许多行业都是如此,比如空中、陆地或海洋交通工具,医疗设备,以及消费电子设备等等。在所有这些行业,标准的做法是交付多款包含相同元素的产品,形成产品线产品系列。在整个产品线或系列中重用资产是减轻产品设计压力的一种主要的效率改进方式。

可以通过许多方法来重用资产;一些方法可能没有其他方法那么高效,但对利用现有工作很有用。当某个公司向新项目重新应用资产和技术时,在一个位置对一项资产的后续更改通常不会完全高效地传播到使用该资产的所有位置。工作的重复就好像没有流程和工具来自动化重用。

在公司内从总体上开发一个精心设计的流程,利用该流程来最大程度地提高资产在整个产品生命周期中的重用,这对提高设计效率和管控复杂性至关重要。战略性重用 是一种重用资产的总体业务战略。

本文将介绍如何在产品线内执行战略性重用。

本文中提出的解决方案可以解决以下重要问题:

  • 浪费时间和资金来开发公司的其他产品中已存在的组件
  • 由于难以知道资产已在哪些地方得到重用,资产更改的传播效率低下
  • 由于低效容易出错的手动流程,产品质量收到损害。

Rational 系统和软件工程解决方案

Rational 系统和软件工程 (SSE) 平台构建于 Jazz™ 平台和开放生命周期协作服务 (OSLC) 协议之上。OSLC 方便了不同生命周期工具与存储库之间的集成,比如需求管理工具、设计和分析工具、实现,以及测试管理工具。

复杂系统开发中的重用场景

复杂系统开发项目中的一种常见场景如 图 1 中所示。该场景显示了一个不断在开发的基础产品,以及不断开发的该产品的变体。变体 1 首先被开发,随后是变体 2 和变体 3。这些变体拥有大量共性,而且它们都基于一个共同的平台。这个共同平台被实现为一个工程资产集合,它包含需求、分析和架构模型、实现工件(比如源代码)和测试工件。

显然,我们的目的是在各个变体中有效地重用平台工程资产,恰当地管理共性和可变性。能够管理工件共享并支持创建工件变体,这至关重要。尽管平台工件在不断开发(由 “核心平台” 箭头表示),但它们经历了一些更改(比如缺陷修复)。这些更改从平台传播到这些变体,如虚线箭头所示。一项更改常常起源于一个变体,随后需要传播回平台开发团队,以便其他变体开发团队可以使用它。管理战略性重用的关键是,实现核心平台和多个变体的并行开发,同时提供准确的上游和下游变更传播。

图 1. 开发一个产品系列
开发一个产品系列
开发一个产品系列

从临时重用到战略性重用

可以通过许多方式重用工程资产。一种类型的重用通常被称为 “克隆并拥有”。资产被复制并由新的所有者维护。在原始或新副本中执行更改后,这些更改不容易传播。这些更改不会传播的原因在于,您不知道一次克隆并拥有(clone-and-own)操作发生了多少次,也不知道克隆的资产位于何处。克隆并拥有方法无法高效地扩展,所以需要更高效的途径来管理和促进共同资产在一个产品线中的产品中的重用。

另一种重用模式是跨多种资产类型定义一种产品配置,这些资产类型称为组件。产品配置结构简化了多个产品中的组件重用。您跨所有工具而创建和管理产品配置:需求、测试、源代码和其他资产。可以复制现有产品配置并更改它来创建新产品变体,替换或删除其分层结构中的一些子配置。

以下重用级别或重用模式 描述了重用资产的高效方式。

战略性重用的基础级别

可以通过不同步方式为重用设计一种工程架构。这些级别不是彼此排斥的;可以针对特定需求对这些级别进行混搭和自定义。产品线开发涉及 3 种分层结构级别:

  • 级别 1:基础级别提供了管理跨各个流的产品变体的核心机制。基于一个连锁的配置管理框架,在所有生命周期学科应用与源代码控制管理 (SCM) 系统中类似的配置管理概念。此能力利用了工件版本、组件配置和分层基准,如本文的 多流变体管理 一节中所述。此级别是 Rational SSE 平台中所有战略性重用功能的基础。
  • 级别 2:第二个级别添加了参数化的资产。维护工件的单一来源,而不是不同的手动流。工件包含基于参数配置而实例化的参数。参数化的资产包含可选的元素和参数的属性值(参阅 多流变体管理),提供了实例化资产的途径。参数配置定义了如何从一个产品线实例化各种变体。
  • 级别 3:第三种能力应用了特征模型。特征模型为外部利益相关者抽象出系统的可变性,基于特征概要文件而指定变体。特征映射到参数,所以一个特定的特定概要文件可为实例配置提供支持,而这些配置可依照第 2 级的功能来实例化变体。特征模型可自顶向下完成,使参数从特征中驱动,或者自底向上执行,使特征映射到现有参数。特征建模通过与第三方 特征建模工具交互来完成,这些工具与 Rational SSE 平台相集成(请参阅 参数化的重用)。

多流变体管理

产品变体具有很高的共性,但您也必须管理它们之间的变化。管理变体的主要方式是使用配置管理中的工件版本

第一个架构层提供了一种分支 机制,利用这种机制从以前定义的产品或变体中创建新变体,如 图 2 所示。每个分支(称为一个)管理一个变体的工件版本。在维护一个通用平台时,还会提供一个流管理通用平台的工件。

每个产品变体是一个生命周期工件集合,这些生命周期工件包括需求、设计模型、代码、测试等。每个变体都会经历一系列基线,这些基线使用圆圈表示。每个基线记录变体中的工件的一种特定状态。在从父变体分支出一个子变体时,子变体通常会从父变 体的一个基线开始,然后继续沿自己的基线时间线发展。斜线表示分支到变体流中。

图 2. 多流变体管理。每个变体都是来自各种工具的一个工件集合。
多流变体管理
多流变体管理

这个多流变体管理框架是 IBM Rational SSE 平台中的战略性重用支持的核心。有两种类型的变体;在这两种类型中,工件都按照 图 2 所示进行管理:

  • 功能变体表示一组不同的功能
  • 时态变体表示同一个产品不同时段的不同版本

流用于管理工件随时间的演变,以便获得某项功能。如果并行开发不同的功能,比如一个产品的两个变体,那么可以使用不同的流。每个流都用于管理工件随时间变化而发生的演变。

一般而言,各个流会保持隔离,所以更改只能被特意 传播到工件中。工程师传送到一个流中的更改在逻辑上被分组为更改集。更改集也可跨流进行传送,尤其是对通用工件进行的更改。通过传送更改集,可以在不同流中保持共性。当存在更改时,多流系统能够提供了一种在工件中保持共性的可掌控的方式。更改集传送可在不同的自动化水平下完成。在与每个流有关联的整体变更管理流程中,会跟踪更改。

组件和配置

复杂系统包含大量工件,这些工件通常被划分为各种逻辑单元(也被称为组件)。组件是重要的战略性重用构建块。组件支持更好地布局工作和供应链流程。工程和软件工件的组件重用基于物理和机械领域多年来使用的类似方法。

每个生命周期工件都贡献了一个特定的工件集合。例如,您可能有一个需求组件和一个建模工件组件。来自多个工具的组件可以组成一个生命周期组件。所以举例而言,一个引擎生命周期组件可能包含该引擎的需求、模型工件、代码和测试。

图 2 中的每个圆圈表示一组组件基线,它们组成整个产品变体的一个基线(显示为一个方框)。基线 是更通用的配置 概念的一种特殊情形。一个组件的一种配置会为它的每个构成工件选择一个特定的版本。基线是一种无法更改的配置,因为它冻结了在特定时刻选择一种可以更改的配置的能力。在 SSE 平台中,组件是重用单元,组件配置是所有系统的构建块。

图 3 演示了一个生命周期学科(在本例中是一个传动系统的需求项目)中的一个组件的多种配置。该产品有一个基线配置。然后,人们开发了具有细微不同之处的配置来满足法规需求 3 个不同市场的具体需求。传动系统需求组件包含 5 个需求,A1 到 A5。需求 A5 有 3 个版本,A5.1、A5.2 和 A5.3。该需求的两个版本的属性值不同:一个汽缸需求可能拥有一个 3 英寸直径版本和一个 4 英寸直径版本。

图 3 显示了传动系统组件的具体配置。

  • 基础配置指定了一组供这些汽车型号重用的需求。型号 A、B 和 C 的配置表示特定于 3 种不同市场的相应汽车型号的需求。他们都从基础配置分支而来。
  • 每种型号可以选择稍微不同的需求版本,但所有 4 种配置的拥有需求 A1、A2 和 A3 的相同版本。
  • 请注意,实际的需求工件可以在不同配置之间进行共享;它们不是副本。
  • 需求 A4 和 A5 在 4 种配置中拥有不同的版本,反映出这些需求在整个产品线中是不同的。
  • 需求 A6 和 A7 只能通过型号 C 的配置进行选择。这些配置不仅选择工件的版本;还选择排除或包含哪些工件。工件可以从某些配置中完全排除。
图 3. 开发了一个基线和 3 种配置来满足不同市场的需求
基线和 3 种不同市场的 3 种配置
基线和 3 种不同市场的 3 种配置

配置会不断演变。在不同的时刻,它可能包含不同的工件版本集合。这样一种配置也被称为。一些配置(叫做基线)无法更改。基线是配置(流)在某个时刻的快照。它们的角色是记录一种配置状态,以便对其进行比较或供以后重用。

每个生命周期工具都是一个组件和配置提供者。同样地,不同的工具通常以不同方式实现配置管理。但是,一些基于 Jazz 的工具(比如 Rational DOORS Next Generation、Rational Design Manager 和 Rational Engineering Lifecycle Manager)将会共享某种通用的配置管理服务。此服务管理这些组件的版本工件,允许定义组件配置,并提供了一种方式来获取一种配置中的一个工件的正确版本。

其他工件,比如 IBM Rational Team Concert™ (RTC) 的源代码控制管理 (SCM) 能力,提供了文件的配置管理,包括源文件。RTC 拥有管理带版本的对象和组件及其配置,跨这些配置执行差分和合并操作(也称为传送)的丰富功能。Rational ClearCase® 支持类似的概念,这些概念在 ClearCase UCM 实现中更加明显。

请注意,多流变体管理框架允许不同的生命周期工具使用自己的配置管理实现。但是,这些不同的实现必须在定义和使用组件、配置和基线的方式上保持一致。

全局配置

每种工具中的组件管理着不同的配置,以便在您构建的工件内实现更细粒度的变体。前面已经提到过,产品由多个组件组成,每个组件拥有多种配置。因此,为了管理一个产品的完整配置,SSE 使用了全局配置。全局配置是来自整个生命周期中的多种工件的一种组合。全局配置可包含其他全局配置来形成配置分层结构,该结构通常与复杂系统的分层性质相对应。图 4 演示了一种全局配置分层结构,这些配置表示一个汽车型号的工程资产。

顶级配置 Model GL 包含完整的汽车型号配置。它包含来自各种生命周期工件的组件,包括需求、总体架构和这个特定汽车型号的产品级测试,还包含该汽车的主要子系统(传动系统 (P) 和外壳 (GL))的其他全局配置。然后,传动系统包含引擎 (4C) 和变速箱 (6S) 的配置。

图 4. 组件组成和分层基线
组件组成和分层基线
组件组成和分层基线

一个组件的全局配置决定了它的子组件的配置。也就是说,汽车的 GL 变体包含外科的 GL 配置和传动系统的 P 配置。请注意,所有这些指定的配置都可能随时间发生变化,类似于一个工具创建的配置,比如需求配置。

全局配置也可以拥有基线。基本上讲,图 5 中的产品基线是全局配置基线。

因为全局配置可以是分层结构的,所以他们的基线可能包含其他基线。这些基线有时被称为分层基线。在 图 5 中,汽车型号 (2014 I1) 的基线表示外壳 (2014 I1) 和传动系统 (2013 I4) 配置的基线,传动系统的基线表示变速箱 (2013 I3) 和引擎 (2013 I3) 配置的基线。

图 5. GL 型号的分层基线
GL 型号的分层基线
GL 型号的分层基线

全局配置基于一种开放、标准化的 OSLC 配置管理 协议。任何工具都可以贡献配置来作为全局配置的一部分,只要它支持 OSLC 配置管理规范。

使用全局配置编辑器定义产品和变体

全局配置编辑器简化了将产品变体定义为生命周期组件配置分层结构的过程。在树式用户界面中,能够以分层结构的方式从组件配置中指定产品配置。基本上讲,该工具定义、管理和可视化了根据组件及其配置来创建产品变体的方式。树中的节点表示组件配置 - 与全局配置对应的内部节点,叶节点表示在生命周期工具内提供和管理的配置。

图 6 演示了使用全局配置编辑器定义的一种汽车变体。产品节点表示组件配置,其中内部节点是全局配置,叶节点与生命周期工具中的配置(也称为局部配置)相关联。顶级节点表示整个汽车产品配置。Car 节点的子节点是汽车的两个主要的子系统:Power train 和 Body。Power Train 变体为 Basic,Body 变体为 Standard。叶节点(表示为不同颜色)连接到各个工具中的各个需求、代码和测试配置。

图 6. 一个汽车产品变体的一种全局配置
一个汽车产品变体的全局配置
一个汽车产品变体的全局配置

多流模式中的一个重要操作是,从现有产品配置中衍生出一个新变体。例如,GL 汽车衍生出一个新变体,名为 LX。要创建分支,需要 “复制一种配置”。然后使用新的 LX 汽车将使用的组件更新该结构内的配置。图 7 显示了配置编辑器如何可视化两种产品变体。在 LX 变体中,您看到了引擎的新的涡轮变体,它拥有需求、代码和测试案例的关联配置。

图 7. 在全局配置编辑器中衍生一个现有产品来创建新产品
衍生一个现有产品以创建新产品
衍生一个现有产品以创建新产品

变体管理实践

在了解如何跨产品变体维护工件和组件后,可以继续处理开发产品线所涉及的其他活动或用例:

  • 创建一个新产品变体:新变体可以通用的平台或一个更具体的变体为基础,使用每个工具(针对需求、模型、代码和测试)和全局配置工具来执行此任务。
  • 设定一个变体的基线:更改各种组件或达到一个里程碑之后,一种常见的做法是为变体设置基线。可以将每个工具中创建的基线组装到整个变体的一个全局基线中。工具支持为基线添加标签,以简化此过程。
  • 导航一个变体的各个组件:举例而言,可跟踪性链接方便了从一个测试案例到一种需求的导航。更改一种需求后,需要更新测试案例的恰当版本。单击该链接时,系统会根据变体的全局配置来抓取测试案例的正确版本。
  • 向变体传播更改和从变体传播更改:在一种产品配置内执行更改时,有时需要将它们传播到其他产品配置。例如,更改一种通用需求时,可以将该更改级联到所有变体,以便保持共性。一些工具支持跨配置传播更改(比如从一种通用配置到一个变体),还支持反向传播。
  • 找到在何处使用组件:在识别某种变体中的问题后,可以通过工具帮助找到其他重用该组件的变体,以便修复可传播到需要的所有变体。一个地方的一项更改的影响分析可以指出需要更改其他哪些变体。
  • 比较变体:快速比较两种变体的结构很有必要,这样就可以显示出共性和可变性。这些工具简化了两个变体的组件结构的比较,您还可以看到工件的详细比较结果。

参数化的重用

您现在已经知道了如何选择配置内的不同工件版本来管理可变性。可以通过分支工件和更改它们来创建不同的版本。

更复杂的系统通常拥有非常多的变体,此外,为了进一步简化变体的创建,可以从一个通用的一般性平台衍生出 变体。一般性的平台组件包含表示一种一般性产品线的参数化工件。参数化的工件可能包含可选的元素或参数化的属性值。然后,您可以为每个产品衍生出属性的特定值或可选元素。

在拥有参数化的工件的一般性平台中,可以通过提供具体的参数配置来自动衍生出工件的不同变体,无需手动分支和修改它们。因此,可以通过应用不同的参数配置,从平台自动衍生出完整的产品配置。

图 8 显示了一个一般性产品结构的例子,该结构包含拥有基于一组参数的条件表达式的组件。这些参数是在一个指定的参数工件中定义的。

产品树显示了一个一般性的汽车结构 (car),其中包含 5 个可选的 组件。Engine 有两个变体,并使用值 “Gas” 和 “Automatic” 作为标签。GearBox 也有两个变体,使用了值 “Automatic” 和 “Manual”。它们通过可变性参数 pGearBox 进行控制。该结构中第三个可选的组件是 sunroof。该结构中的每个组件引用都有一个条件表达式,可用于根据相应参数的设置来确定要包含哪些组件。

图 8. 一个具有可变性参数(在 Rational Engineering Lifecycle Manager 中管理)的一般性汽车平台
具有可变性参数的一般性汽车平台

根据一般性的产品结构,通过创建该一般性产品的流并提供一组具体的参数值,可以衍生出特定的配置。图 9 显示了一种从之前的一般性结构衍生出的产品线结构:

图 9. 基于参数配置而衍生一种汽车产品
基于参数配置而衍生一种汽车产品

图 9 中的变体结构的创建方法是,首先使用一个新产品配置节点,指定一种参数配置作为在产品树中的指定节点。参数节点可以定义可变性参数的具体的参数值。在示例中,参数 pEngine、pGearBox 和 pSunroof 分别被设置为 “gas”、“automatic” 和 “false”。最终,这些参数值可由(它们所在的)产品节点上的条件表达式使用,确定为特定变体结构选择哪些变体节点。“turbo” Engine 变体、“manual” GearBox 变体和 Sunroof 组件已从所示的配置中排除。

如图所示,参数化的产品结构可通过创建变体 来处理,就像非参数化系统一样。但是,在参数化的产品结构中,变体的内容 可通过参数配置 是部分还是全部从一般性平台衍生来确定。

图 10 显示了一种模式,其中的产品线包含参数化的资产并定义了一组可变性参数。每种变体都可以定义一种参数配置,向部分或所有可变性参数提供值,进而将产品线实例化为产品。请注意,与基本分支相反,这里的变体包含从参数设置自动衍生出来的工件版本。

图 10. 参数化的变体
参数化的变体
参数化的变体

大多数变体都是从产品线之前的一个基线中衍生而来,开发工作仍在一般性产品线中继续。然后,可以依据变体的参数配置中提供的值,实例化参数化的一般性工件,从产品线基线衍生出变体的基线。这种衍生过程由 图 10 中的虚线箭头表示(图 2 中使用这些箭头来表示传播。衍生就像是在传播之后执行实例化。)

但是,完全可以在产品变体中进行开发,得到一些不是自动从产品线衍生出来的工件。更改可能使用标准的更改传送机制反映到产品线中。

特征驱动的重用

如果与前面介绍的重用模式相结合,特征建模可进一步增强变体管理。产品线的可变性可以使用特征模型 抽象出来。特征模型表示一个系统作为分层树的可变性,这个树由称为 “特征” 的节点组成。特征表示用户可以看到的系统功能。特征模型描述了系统的特征变体,因为它表示备用特征和可选特征,这些特征将在产品线中指定一种变体。特征被组装到一个特定模型中,可以使用一些关系来描述强制、备用或可选特征。

备用特征表示需要选择一种可能的特征,如图 11 中分组传入的实心三角形所示。可选特征可以使用一个中空圆圈附加到某一条边上。各边表示父节点上下文中的强制特征。特征模型也可显示特征中的约束条件 - 例如一个需要知道涉水深度 xlt混合 引擎。这些约束可帮助产品线经理指定有效的特征组合。一个变体包含一组特征。

从技术上讲,一个变体包含的这组特征,类似于向一个一般性产品应用参数配置来衍生出特定于变体的工件。因此,特征模型可放在参数化的组件顶部,将特征与解决方案的可变性参数相关联。图 8 中提供的参数表示与 图 11 中所示的类似的特征选择。

图 11. Car 特征模型
Car 特征模型
Car 特征模型

图 12 显示了这个特征模的一个特征选项如何映射到促使一个变体工件的配置的一种参数配置。

图 12. 促使特定于变体的工件的特征选择
促使特定于变体的工件的特征选择
促使特定于变体的工件的特征选择

要从特征选择中衍生出一组参数,必须在特征与资产所使用的参数之间建立一个映射框架,确保它们之间存在 1:1 的对应关系。这个映射框架必须与特征建模功能一起提供。

汽车系统的 AUTOSAR 规范框架中就使用了特征与可变性参数之间的映射(在 AUTOSAR 中,可变性参数被称为系统常量)。

目前 Rational SSE 平台未直接提供特征建模服务。这些服务可以通过 Rational SSE 平台与特征建模工具(比如 Big Lever Software 所提供的 Gears 和 pure-systems GmbH 所提供的 pure::variants)之间的接口来提供。

结束语

Rational SSE 平台中的重用功能支持在生命周期的各个部分中跨工程工件而重用,还支持在整个系统中模块化地重用组件。通过重用组件,跨不同变体应用恰当的变更管理,并利用自动化机器来控制重用和建立健全的变体控制流程,可以解决高效重用的一些难题。

3 种架构级别所提供的选项,方便了依靠系统的复杂性而扩展重用:多流变体管理、参数化和特征建模。

本文中列出的解决方案方法是开放 的,提供了一组基于开放协议的模块化的功能,所以您可以将不同的专业系统工程工具集成到该框架中。这里列出的功能简化了战略性重用,降低了维护成本,加快了上市速度,节省了公司资金。

致谢和免责声明

感谢 Daniel Moul 和 Ronnie Seagren 审阅本文并提供许多很有帮助的注释。他们帮助使用最新的方向和术语变化而更新了本文,为阐明内容的最新状态做出了巨大贡献。还要感谢 Steve Di Camillo、Bruce Douglass、Mats Gothe 审阅本文的早期草案。非常感谢 Ran Rinat 为本文的初始版本提供构想。

本文中提出的技术愿景包括想要的未来产品方向和战略。

IBM 有关其计划、方向和意图的陈述随时可能由 IBM 全权更改或撤销,恕不另行通知。与潜在的未来产品相关的信息仅用于列出我们的一般产品方向,不应赖以制定购买决策。提及的与潜在未来产品相关的信息不是对提供任何材料、代码或功能的承诺、允诺或法律责任。有关潜在的未来产品的信息不得合并到任何合同中。所描述的我们的产品的任何未来特征或功能的开发、发布和时间安排由我们全权决定。

IBM Rational 工具设计为您全面的软件开发流程的一部分。与任何开发最佳实践一样,您应负责开发和充分测试您的应用程序和相关系统,包括与注重安全的功能相关的应用程序。

© 版权所有 IBM Corporation 2014

IBM Corporation Software Group, Route 100, Somers, NY, 10589, U.S.A.

在美国印刷

保留所有权利


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=991721
ArticleTitle=战略性重用和产品线工程
publish-date=12042014