软件产品线体系结构

软件产品线在软件工程中地位

软件产品线的基本概念

将利用了产品间公共方面、预期考虑了可变性等设计的产品族称为产品线(Weiss和Lai)。
产品线就是由在系统的组成元素和功能方面具有共性和个性的相似的多个系统组成的一个系统族。
软件产品线就是在一个公共的软件资源集合基础上建立起来的，共享同一个特性集合的系统集合(Bass,Clements和Kazman)。
一个软件产品线由一个产品线体系结构、一个可重用构件集合和一个源自共享资源的产品集合组成，是组织一组相关软件产品开发的方式(Jan Bosch)。
CMU/SEI：产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统遵循一个预描述的方式，在公共的核心资源基础上开发的。
根据SEI的定义，软件产品线主要由两部分组成：核心资源、产品集合。核心资源是领域工程的所有结果的集合，是产品线中产品构造的基础。也有组织将核心资源库称为“平台”。
核心资源必定包含产品线中所有产品共享的产品线体系结构，新设计开发的或者通过对现有系统的再工程得到的、需要在整个产品线中系统化重用的软件构件。

软件产品线的过程模型 – 双生命周期模型

软件产品线的过程模型 – SEI模型

软件产品线的过程模型 – 三生命周期模型

软件产品线的组织结构 – 典型结构

软件产品线的组织结构 – SEI产品线组织结构

市场人员是产品线和产品能力、客户需求之间的沟通桥梁；
核心资源组负责体系结构和其他核心资源的开发；
应用组负责交付给客户的系统的开发；
管理者负责开发过程的协调、商务计划等。
设有独立核心资源小组的组织结构通常合适于至少由50到100人组成的较大型的软件开发组织，设立独立的核心资源小组可以使小组成员将精力和时间集中在核心资源的认真的设计和开发上，得到更通用的资源。
不设立独立的核心资源小组，核心资源的开发融入各系统开发小组中，只是设立专人负责核心资源开发的管理。这种组织结构的重点不在核心资源的开发上，所以比较适合于组成产品线的产品共性相对较少，开发独立产品所需的工作量相对较大的情况。也是小型软件组织向软件产品线开发过渡时采用的一种方法。

软件产品线的组织结构 – Jan Bosch产品线组织结构

开发部门：所有的软件开发集中在一个部门，每个人都可承担领域工程和应用工程中适合的任务，简单、利于沟通，适用于不超过30人的组织。
业务部门：每个部门负责产品线中一个和多个相似的系统，共性资源由需要使用它的一个和几个部门协作开发，整个团体都可享用。资源更容易共享，适用于30-100人的组织，主要缺点是业务部门更注重自己的产品而将产品线的整体利益放在第二位。
领域工程部门：有一个专门的单位——领域工程部门负责核心资源库的开发和维护，其他业务单位使用这些核心资源来构建产品。这种结构可有效的降低通讯的复杂度、保持资源的通用性，适于超过100人的组织。缺点是难以管理领域工程部门和不同产品工程部门之间的需求冲突和因此导致的开发周期增长。
层次领域工程部门：对于非常巨大和复杂的产品线可以设立多层（一般为两层）领域工程部门，不同层部门服务的范围不同。这种模型趋向臃肿，对新需求的响应慢。

软件产品线的建立方式

演化方式

革命方式

基于现有产品

基于现有产品架构设计产品线的架构，经演化现有构件，开发产品线构件

优点：风险最小，第一个产品面世时间早

缺点：完成产品线核心资源的总周期和总投资较大

核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集

优点：开发一个不受现有产品集存在问题限制的、全新的平台，总周期和总投资较少

缺点：风险大，第一个产品面世的时间会推后

全新产品线

产品线核心资源随产品新成员的需求而演化

优点：先期投资少，风险小，第一个产品面世时间早，可以减少因经验不足造成的初始阶段错误的修正代价

缺点：已有的产品线核心资源会影响新产品的需求协调，使成本加大

开发满足所有预期产品线成员的需求的核心资源

优点：一旦产品线核心资源完成，新产品的开发速度将非常快，总成本也将减少

缺点：风险大；对新领域的需求很难做到全面和正确，使得核心资源不能像预期的那样支持新产品的开发

软件产品线的演化

从整体来看，软件产品线的发展过程有三个阶段，开发阶段、配置分发阶段和演化阶段。
引起产品线体系体系结构演化的原因：产品线与技术变化的协调、现有问题的改正、新功能的增加、对现有功能的重组以允许更多的变化等等。
产品线的演化包括产品线核心资源的演化、产品的演化和产品的版本升级。这样在整个产品线就出现了：核心资源的新旧版本、产品的新旧版本和新产品等。它们之间的协调是产品线演化研究的主要问题。

框架和应用框架技术 – 一般框架的定义

Deutsch：多个抽象类和它们相关算法的集合可组成一个框架，该框架在特定应用中可以通过专用代码的添加来将具体子类组织在一起运作。框架由抽象类及其实现的操作和对具体子类的期望组成。
Johnson和Foot：框架是封装了特定应用族抽象设计的抽象类的集合，框架又是一个模板，关键的方法和其他细节在框架实例中实现。
Buschmann：框架是一个可实例化的、部分完成的软件系统或子系统，定义了一组系统或子系统的体系结构并提供了构造系统的基本构造模块，还定义了对特殊功能实现所需要的调整方式。在一个面向对象的环境中，框架由抽象类和具体类组成；框架的实例化包括现有类的实例化和衍生。
Johnson：框架=模式+构件。框架是由开发人员定制的应用系统的骨架，是整个系统或子系统的可重用设计，由一组抽象构件和构件实例间的交互方式组成。

框架和应用框架技术 – 应用框架的定义

Gamma：应用框架又称为通用应用，是为一个特定应用领域的软件系统提供可重用结构的一组相互协作的类的集合。
Buschmann：特定领域应用的框架被称为应用框架。
Froehlich：应用框架就是某个领域公共（generic）问题的骨架式解决方案。框架为该领域所有应用提供公共的体系结构和功能基础。
Batory：应用框架技术是用于应用产品线的、通用的、面向对象的代码结构化技术。一个框架就是表达抽象设计的抽象类的集合；框架实例就是为可执行子系统提供的抽象类的子集的具体类的集合。框架是为了重用而设计的；抽象类封装了公共代码，具体类封装特定实例的代码。

框架和应用框架技术 – 框架的特征

反向控制：类库是客户代码调用库中已存在类的方法。框架内嵌了控制流，框架调用客户代码——加入框架的新构件和抽象类的方法实例。
可重用性：框架提供了设计和代码的重用能力。
扩展性：为规划的变化提供了“热点”（hotspot）或“钩子”（hook）等显式说明方式。
模块化或构件化：框架有固定的、稳定的接口和封装的热点。

框架和应用框架技术 – 框架的建立方式

一般框架有三种建立方式：自顶向下，自底向上和混合方式。
因为应用框架和软件产品线之间的密切关系，前两种框架建立方式与建立全新的软件产品线时的革命方式和演化方式十分类似，也具有相同的过程和优缺点。
混合方式指在大型应用框架的建立过程中，先将应用领域划分为不同的子区域，再分别解决，最终集成为一个完整框架的做法。

框架和应用框架技术 – 框架的分类

黑盒框架通过构件/类的组合来支持重用和扩展。应用中的类由框架的不同构件组合而成。在框架所在领域中，每个构件都有一个预定义的标准接口，一组共享相同接口但能满足不同应用需求的构件组成一个“插接兼容”的构件集合。
白盒框架一般使用类的继承机制实现，由未完成的类（抽象类）组成，类有一个或多个抽象接口或虚方法。应用需要在抽象类的继承子类中提供特定意义的方法实例来重用框架。开发者通过虚方法的实例化将特定应用的代码联入框架来生成应用。
灰色框架可以分成三部分：固定的、可选择的和开放的。框架的固定部分包含了该领域最基本的功能、内建了应用的控制流，由框架主干实现，对应着领域共用部分。框架的可选择部分为该领域中相对固定的、应用特定的功能特征即领域个性部分，用可组合的类或构件实现，在应用构造时在这些构件或类中进行选择、组合。对一些无法准确估计和预测的功能特征即框架的开放部分，只能为其规定统一的接口和与框架的挂接点，用可继承的抽象类的方式来实现，这些部分可以根据应用的具体需求变化进行单独的调整。