严肃的介绍软件产品线工程

面对日益复杂的软件系统,软件复用被认为是解决“软件危机”、提高软件开发效率和质量、实现软件产业工业化生产方式的重要途径。

多年来软件复用的研究和实践表明,面向特定领域的软件复用活动相对容易取得成功。这里的领域不是大众印象中的金融领域、教育领域等行业领域，而是指一组具有相似和相近软件需求的应用系统，这些应用系统实现相同的主要功能，有着大致相同的体系架构，但又有合理的个性化诉求，以满足不同组织差异化的经营模式。

特定领域的软件复用相对容易获得成功，被认为能取得成功的原因如下：

领域的内聚性：领域知识逻辑上具有紧密相关性；

领域的稳定性：在一定时间内,领域知识不会发生剧烈的变化；

与传统面向单应用的软件工程方法不同，软件产品线方法关注于核心资产的开发，以及将这些核心资产适配到不同的应用系统中。

这里的核心资产不仅仅是软件代码或构件，还包括需求、体系结构、测试用例等。为了满足不同受众对应的应用系统的个性化需求，产品线理论中引入可变性模型的概念，这种共性/可变性的分析思维模式，贯穿整个软件开发的生命周期。

为了更好地区分核心资产开发与应用，软件产品线工程将整个研发过程分为2个过程：

领域工程（Domain engineering）：这个过程负责建立一个可复用的平台，定义产品线的共性与可变性，创造可复用的核心资产（领域需求、参考体系结构、构件、测试用例）。领域工程的成功，很大程度上取决于积累的领域知识。透彻了解市场和客户的领域专家，可以有效预见和识别领域共性及可变性。

应用工程（Application engineering）：新系统的开发不再是从零开始，而是建立在对分析、设计、实现等阶段的软件资产大量复用的基础上，根据具体应用需求（确定可变点），复用这些资产创建应用系统。

在实际运作的过程中，这两个过程经常互相交互，彼此促进。应用工程中，经常会根据不同客户实际情况，丰富领域知识，对共性/可变性模型进行演化，增强领域模型。而领域模型的不断迭代，会促进下一个项目的应用开发效率与质量。

好的，可以开始讲人话了。

比如现在要为几家客户开发金融超市应用，先从领域工程做起。

首先，拿到业务需求以后，先不急着开始做，而是让来自各个团队的大佬坐在一起，根据他们丰富的经验和预见未来的能力，讨论一下这个应用大概长成什么样子，有什么功能，需要接入什么技术等。按照讨论结果建立一个特征模型，然后走一遍开发流程，得到一个兼容各种情况的超级产品，这个超级产品包括了金融超市应用必需的各种模块，且需求文档、架构、测试资产一应俱全。

注意此时，大佬们除了要总结出这一系列金融超市的共性之外，还要标记哪些地方可能会出现不同，这样才方便后续对这一系列产品的修改和裁剪。

完成了第一步后，接着来到第二步：应用工程。

这时候只需要按照顾客的要求给超级系统做需求的裁剪，像搭积木一般装配出来客户需要的应用系统。同时在定制过程中也要给第一步提供反馈：“明明大家都是瘦子你为什么要设计成胖子的款式”，“金链子太老土了现在都流行用电线作佩饰了”……及时修正超级系统，使改动幅度尽可能的小，等软件已经按照要求修改完毕后，就可以把产品交给客户了。

需要指出的是，此时的产品和真正的产品线上的产品还有一些不同：它们都是连体婴儿。它们都分享着在第一步中设计出的“超级”系统，而不是一个个完全独立的产品。

传统的需求分析方法一般有五个步骤：需求获取、需求分析、规格说明、需求验证、需求管理。业务分析人员，通过有目的和计划的交流以明确用户想要达到的效果，在此基础上用UML等工具进行需求建模，然后用规范无异议的语言进行描述说明，同时考虑预算、可移植性、可维护性等方面的非功能性需求。

产品线工程中的需求分析，并不是对传统软件需求分析方法的颠覆，而是站在领域共性/可变性分析的高度，系统化地思考问题域。

它和传统需求分析方法比，有如下不同：

需求分析过程中，需要识别哪些是对于所有应用共性的特征，哪些是针对特定应用需要调整的；

为了适应对领域需求的复用要求,领域模型不仅要记录领域内的系统具有的共性功能和质量属性，还要记录这些属性可能具有的变化性。所有需求中可能的选择，都显式地通过可变性模型(variability model)建模；

除了基于客户的反馈，领域需求分析还要考虑到未来需求可能的变化，例如因法律、标准、市场需求等引起的未来变化；

领域需求，指导领域设计阶段和实现阶段可复用软件资产的生产；

传统的需求分析，一般使用数据流图（DFD）、UML来表示需求。

数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。

UML中，用例图(Use Case Model)从用户角度描述系统功能，并指代各功能的操作者。活动图描述了业务实现用例的工作流程。状态图描述状态到状态控制流，常用于动态特性建模。类图也经常用于需求分析，描述系统潜在的实体，以及实体之间的关系。

传统需求模型的薄弱点在于对于共性/可变性的描述能力不足。因此多年前学术界围绕着领域分析作了各种尝试，比较著名的有FODA(Feature-oriented Domain Analysis)，旨在建立特征模型以直观描述系统共性和特性，包括实现功能，接口技术，专业技术等等；ODM(Organization Domain Modeling)，着眼于对整个领域工程而非某个特定的系统建模；以及我们将要讨论的FORM(Feature-oriented Reuse Method)，在FODA的基础上加上了对非功能需求的分析和对组件具体使用的指导。

领域工程中，经常把特征(feature)作为系统需求规约的组织方式。特征是从用户角度对系统的感知,用特征对系统需求规约进行模块化组织是一种非常自然的手段。以特征模型为中心,由多种相关模型(用例模型、数据流模型)共同构成领域模型的方法，逐渐成为各种方法共同采用的手段。

通常，一个特征模型描述一个相对独立的需求实体。特征模型在关注单个特征的同时，也注重挖掘特征之间存在的关系。特征模型的基本组织结构提供了一种把各个独立的特征组织在一起的方式，从而描述出领域中的共性与可变性。

下图是一个典型的特征模型，描述在金融超市中绑定银行卡的需求。在应用系统A中，绑定他行卡必须首先上传用户身份证进行OCR识别及证件照片比对，然后完成鉴权后才能开通电子账户，并且只允许同时绑定一张他行卡关联到电子账户。而在应用系统B中，只需要通过鉴权即可开通电子账户，并且允许同时绑定多张他行卡到一个电子账户中。

特征模型提供了多种表示领域变化性的机制：必选特征Mandatory Feature、可选特征Optional feature、可选（多选一/多选多）特征Alternative feature。

可以看到特征模型的层次之间存在2种类型的关系：

1）整体特征对部分特征的控制和协调作用，例如：他行卡绑定特征与其子特征（OCR识别、证件图片比对、鉴权、开通电子账户）就反映了整体特征对部分特征的控制和协调作用。用矩形表示。

2）整体特征和部分特征逻辑上的紧密结合性，例如：他行卡绑定特征与子特征（允许绑定数量特征）则反映了整体特征和部分特征逻辑上的紧密结合性，即允许绑定数量是他行卡绑定执行过程中体现出来的行为特点,允许绑定数量不能脱离他行卡绑定而单独发生作用。用圆角矩形表示。

除了本功能内整体特征与部分特征之间的关系，不同功能间特征的相互依赖也不容忽视。为了满足本功能的某特征，很有可能会影响到另一功能的实现方法。比如在系统B中，同一个电子账户绑了N张卡，则为了防止几张卡间资金流通，系统B就不能像A一样直接实现账户充值，B的充值特征模型必然与A不同。

在应用工程阶段，通过对领域特征模型的剪裁和扩展，可以得到单个应用系统的需求规约。

对特征模型的剪裁存在两种不同的活动:

(1) 绑定一部分变化性特征(针对Alternative feature)

(2) 删除一部分变化性特征(针对Optional feature)

针对上面的例子，对系统A，裁剪后的特征模型如下：

对系统B，则有特征模型如下:

虽然相对于传统的软件工程流程，软件产品线工程模式在初期的投入可能更高。但是磨刀不误砍柴工，鉴于这一系列产品有很大一部分用的是同一套系统，这种产品线的模式有很多好处。

首先它提高了开发效率，开发团队得以用更短的时间满足客户的需求；其次它降低了维护难度，维护团队不再需要对所有系统一一改进完善；第三它减小了出错概率，因为同一套系统需要经受比一般系统多几倍的测试，错误能够更及时地被发现、纠正。

作者：兴业数金公司研究开发总部 杨益明 吴思旖 殷静雯