第六讲 软件产品线

软件产品线主要内容：一、发展历程二、定义三、框架四、主要研究内容一、发展历程

软件产品线的概念最初是由卡耐基梅隆大学的软件工程研究所(CMU-SEI)在一系列工业界特定领域软件开发的成功经验基础上所提出来的。一、发展历程2000年，SEI发起召开了第一届国际软件产品线会议SPLC(SoftwareProductLineConference)，并提出一个完整的、经实践确认的软件产品线开发方法。除此之外，ICSE(InternationalConferenceontheSoftwareEngineering)、ICSR(InternationalConferenceontheSoftwareReuse)、ICRE(InternationalConferenceontheRequirementsEngineering)等主流软件工程会议也将软件产品线作为一个主要的关注点。一、发展历程

不少国际知名软件企业的研究所也对软件产品线工程产生了浓厚的兴趣，如IBM于2003年将软件产品线作为其全球技术展望的一部分，Microsoft也将软件产品线作为其提出的软件工厂工具环境的根本激发因素，SAP则提出了特征驱动、面向方面、基于模型驱动体系结构的产品线开发项目feasiPLe。一、发展历程

除学术研究外，不少国内外软件公司和研究机构也推出了自己的软件产品线系统和开发工具。一、发展历程BigLever软件公司的GEARS为创建软件大规模定制生产线提供了底层框架和开发环境，它由大规模定制底层框架、开发环境和大规模定制驱动器三部分组成。其中底层框架对软件结构进行组织，使其能够适合于大规模定制；开发环境提供编辑器、浏览器等工具以方便对产品线进行创建、修改和维护等操作；驱动器则用于运行产品线生产软件产品实例。通过与传统的软件工程工具和技术联合使用，GEARS可以方便地对面向单一软件产品开发的系统进行扩展，实现软件产品的大规模定制生产。一、发展历程ESAPS(EngineeringsoftwareArchitectures，ProcessandPlatformsforSystemFamlies)作为欧洲6个国家12家公司和10家研究机构合作研发的项目，旨在为大型软件组织引入产品家族开发概念，以提高医学成像、移动电话、航班控制、能源销售和汽车电子等领域的嵌入式软件和分布式软件产品的开发效率。ESAPS结合商业、体系结构、流程和组织四个开发关注点，试图从开发样式和复用两个层面来提高软件产品生产率，并已经在Philips、Nokia、Siemens、Thales和Telvent等公司推广试用。一、发展历程

国内北京大学软件工程研究所在青鸟工程中引入软件生产线的概念和思想，实现了一个支持对可复用构件进行描述、管理、存储和检索的构件库，将软件的生产过程划分为三类不同的生产车间，即应用体系结构生产车间、构件生产车间和基于构件、体系结构复用的应用集成车间，将软件开发人员划分为构件生产者、构件库管理者和构件复用者，从而形成软件产业内部的合理分工，实现软件的工业化生产。一、发展历程

软件产品线在软件产业界也得到了很好的实践。早在上个世纪90年代，美国国防部的NUWC(NavalUnderseaWarfareCenter)中心就开发了RangeWare产品线及其资产基础；ATAPO(ArmyTechnologyApplicationsProgramOffice)则成功地为美国陆航特勤队(Army’sSpecialOperationsHelicopters)的战场软件开发了软件产品线系统；同时，软件产品线方案也被美国军方的FBCB2(ForceXXIBattleCommandBrigadeandBelow)和FCS(FutureCombatSystem)系统所采用。一、发展历程

在工业界，ABB的燃气涡轮控制软件，Boeing的航空设备电子软件、Philips的OpenTV交互式机顶盒软件和医学影像软件，以及包括siemens、Nokia等在内的一系列国际知名企业均采用了软件产品线方法用于开发和维护面向不同用户需求的软件产品家族。其他著名的应用范例还有瑞典CelsiusTechsystem公司和美国空军电子系统中心(ESC)的产品线系统等。二、定义

卡耐基-梅隆大学(CMU)的软件工程研究所(SEI)给出了软件产品线的经典定义[3]，他们认为“软件产品线是指共享一组可管理特征，满足特定的市场需要或任务需要，并且按照预定的方式以公共核心资产为基础开发而来的一系列软件系统”。二、定义Lee等认为软件产品线工程是“一种新兴的软件工程范型，指导着软件开发组织利用核心资产进行软件产品开发，而不是从零开始”。强调了核心资产的开发和利用核心资产进行产品开发[4]。二、定义Bosch，认为软件产品线由“一个产品线体系结构，一组可复用构件和由共享的核心资产派生的产品集合构成”。这个观点从产品线构成元素的角度给出[5]。二、定义Krueger，将软件产品线定义为“一种工程技术，使用通用的产品构建方法，从一组共享的软件资产构建相似的软件系统”。这个定义强调了软件产品线的工业化生产方式[6]。二、定义Pohl等给出的定义是“软件产品线工程是使用平台和大规模定制技术开发软件应用程序(软件密集型系统和软件产品)的范型”。他们关注于公用平台的地位和产品的个性化定制[7]。三、框架

基本框架

SEI实践框架

FORM方法框架

Pohl等人提出框架三、框架--基本框架

软件产品线基本框架包括三个基本的过程：领域工程(DomainEngineering)、应用工程(ApplicationEngineering)和领域管理(DomainManagement)。领域工程是产品线核心资产的生产阶段，而应用工程则是基于核心资产的应用产品生产阶段，领域管理是对上述两个过程的协调管理。三、框架--基本框架

软件产品线基本框架包括三个基本的过程：领域工程(DomainEngineering)、应用工程(ApplicationEngineering)和领域管理(DomainManagement)。领域工程是产品线核心资产的生产阶段，而应用工程则是基于核心资产的应用产品生产阶段，领域管理是对上述两个过程的协调管理。三、框架--基本框架

领域工程一般分为领域分析、领域设计和领域实现这三个子阶段。领域分析的产物是描述领域共性和可变性需求的领域需求模型(DomanModel)，领域需求模型是对产品线领域的范围定义以及对领域需求的表现形式；领域设计在领域需求模型的基础上实现产品线体系结构的设计，包括概念构件、构件间的交互和组合方式以及体系结构可变点；领域实现依照领域体系结构所提供的构件规约创建核心构件资产。三、框架--基本框架

在这些开发设计活动中，不同阶段的产品线模型与实体代表了不同参与者的关注点，也展示出产品线不同的设计与实现形态。另一方面，这些模型与实体并非相互独立，他们是循序渐进的开发产物，具有内在的关联本质。三、框架--基本框架

应用工程阶段也包括相应的需求分析、设计和实现活动，它们都是以相应的核心资产为基础的复用式开发过程，同时也包括一部分面向特定应用需求的适应性修改和扩展。因此，大多数软件产品线开发方法也强调应用工程对于领域工程的逆向反馈以及领域核心资产与应用产品的协同和一致性演化问题。三、框架--基本框架

领域管理(包括技术和组织管理两个方面)被视为与核心资产开发(领域工程)和产品开发(应用工程)并列的三个基本活动之一，并特别强调成功的产品线需要持久的、强有力的、有远见的管理。这主要是由于软件产品线涉及领域工程和应用工程两个层面，而应用工程中又包含多个并可能随时间推移不断增加的应用产品。此外，软件产品线往往是一个长期的投资过程，需要经历领域发展、成熟以及核心资产不断积累的过程。因此，在长期的软件产品线开发和不断演化过程中，如何管理各种开发活动、协调核心资产与应用产品两个层面上的开发和演化就显得十分重要了。三、框架--SEI实践框架

SEI给出了软件产品线实践框架[8]。该框架目前包含29个活动域，划分为三类实践域：软件工程实践域、技术管理实践域和组织管理实践域。框架的具体内容如下表所示。三、框架--SEI实践框架

SEI给出了软件产品线实践框架[8]。该框架目前包含29个活动域，划分为三类实践域：软件工程实践域、技术管理实践域和组织管理实践域。框架的具体内容如下表所示。三、框架--FORM方法框架

FORM方法[9][10]，是一种典型的面向特征的产品线工程方法，它对FODA进行了扩展，沿用了其面向特征的领域分析方法，并将特征概念推广到领域设计和领域实现阶段，利用领域分析得到的特征模型去开发体系结构和构件等工件。在FODA中，需求作为领域分析的输入，在FORM中，领域中的相关活动很大程度上还受到市场因素和产品计划的影响。市场和产品计划识别了市场和业务分析活动中得到的信息，比如市场分析、市场策略、产品特征和产品特征配置方法等。市场和产品计划使得产品线中的复用远离了随机化方式，转变为一种预先定义的方式，使得复用活动更加一致和系统化。三、框架--FORM方法框架

FORM产品线工程包含两个主要过程：领域工程和应用工程。领域工程包含产品线分析和基于分析结果的参考体系结构和可复用构件的开发。参考体系结构和可复用构件既包含了领域中系统间的共性，也包含了系统的个性。应用工程包含针对产品的需求分析、特征选择、体系结构选择和使用、构件剪裁和代码生成。单个产品的开发应该充分利用领域工程的输出工件，这使得应用工程阶段活动与传统的单个软件系统的开发活动具有很大的不同。下图显示了FORM的两个工程过程：三、框架--FORM方法框架

FORM产品线工程包含两个主要过程：领域工程和应用工程。领域工程包含产品线分析和基于分析结果的参考体系结构和可复用构件的开发。参考体系结构和可复用构件既包含了领域中系统间的共性，也包含了系统的个性。应用工程包含针对产品的需求分析、特征选择、体系结构选择和使用、构件剪裁和代码生成。单个产品的开发应该充分利用领域工程的输出工件，这使得应用工程阶段活动与传统的单个软件系统的开发活动具有很大的不同。下图显示了FORM的两个工程过程：三、框架--Pohl等人提出框架

该框架分为领域工程与应用工程两个层次。领域工程包括产品管理、领域需求工程、领域设计、领域实现以及领域测试这五个子过程。这些过程负责确定领域边界，分析领域的共性与变性需求，并提供参考体系结构，同时指导领域构件与测试用例的开发。应用工程使用以上子过程生产的产品线核心资产，在应用需求工程、应用设计、应用实现和应用测试活动中对资产进行定制、组装与测试，得到最终的应用实现。三、框架--Pohl等人提出框架

另外，在两个工程阶段中都具有箭头表示的反馈，这说明软件产品线处在不断的演化过程中，已有的核心资产可能无法适应新的需求，这种演化的驱动力可能来源于产品线自身，也可能由应用系统的独立演化所提出。三、框架--Pohl等人提出框架

另外，在两个工程阶段中都具有箭头表示的反馈，这说明软件产品线处在不断的演化过程中，已有的核心资产可能无法适应新的需求，这种演化的驱动力可能来源于产品线自身，也可能由应用系统的独立演化所提出。四、主要研究内容领域分析领域设计构件及构件库设计可变性分析与管理产品线进化与再工程产品线评估与测试产品线组织模型与经济模型四、主要研究内容一、领域分析领域分析方法主要有基于特征、场景、目标等。四、主要研究内容一、领域分析1、基于特征的领域建模自从特征的概念被引入到产品线开发后，基于特征的领域分析技术就成为主流并且得到广泛应用。特征(feature)来源于电信行业，后来被证明其完全适用于软件开发活动，因此研究者在软件开发与设计阶段提出了特征工程的概念。四、主要研究内容一、领域分析1、基于特征的领域建模相关研究者提出了特征的一系列定义。其中，张伟等学者从内涵及外延两方面对特征进行了描述：从内涵上说，特征是独立需求的紧密集合体；从外延上说，特征是用户可见的系统功能与特性。特征作为问题空间内的一阶实体，表述了系统被期望实现的功能与品质。在产品线领域模型中，特征能够有效地表示领域内的需求，并且作为表达领域内共性与可变性的基本单元。四、主要研究内容一、领域分析1、基于特征的领域建模特征模型是基于特征的领域模型的一种表现形式，它可采用图形化的方式表达领域的需求，定义特征及其关系。四、主要研究内容一、领域分析1、基于特征的领域建模1）特征模型建模特征模型的建模技术包括特征模型的模型表达以及特征建模过程。四、主要研究内容一、领域分析1、基于特征的领域建模1）特征模型建模一般情况下，无论使用何种表达方式，特征模型的结构均被分为分解与特化。特征的分解将一个父特征分割为一系列功能独立、使用相关的子特征；而特征的特化将一个表示抽象功能的特征转换为更加具体的子特征。四、主要研究内容一、领域分析1、基于特征的领域建模1）特征模型建模特征模型需要表达需求的共性与可变性，在常用的特征模型中，共性需求被设计为不变特征(mandatory)，表示该特征被领域内所有应用系统所共享。需求的可变性又可分为三类：第一是可选(optional)，表示一个特征在应用系统中可以被选择或不被选择；第二是多选一(alternative)，表示一个抽象特征在其特化子集中的选择策略，但同时只能选择其中一个；第三是多选多(OR)，与多选一可变性类似，但允许同时选择多个特化子特征。

四、主要研究内容一、领域分析1、基于特征的领域建模1）特征模型建模特征依赖(featuredependency)是特征模的重要组成部分，表示了特征之间的相互作用关系。特征依赖的重要性在于它能够实现领域内可复用资产的组织，并且支持他们的定制过程。特征依赖一般可分为静态依赖与动态依赖。静态依赖表示在特征模型设计和定制过程中的配置依赖，特征之间不存在直接的功能交互。另一方面，动态依赖表示特征在运行过程中的交互，这种交互过程可能是同步的，也可能是异步的。

四、主要研究内容一、领域分析1、基于特征的领域建模1）特征模型建模在特征建模过程方面，FODA与FORM为基于特征的领域分析提供了指导。FODA中的领域分析主要包含上下文分析(ContextAnalysis)和领域建模(DomainModeling)两阶段。在上下文分析阶段，领域分析员与对用户进行调研，确定领域的边界得到上下文模型(ContextModel)。在领域建模阶段，领域分析员使用信息源和上下文分析的其它产品，产生领域分析模型，包括特征模型(表示了领域中一组系统的标准特征以及这些特征之间的关系)、信息模型(用领域中的数据实体及其相互之间的关系表示领域知识)以及功能模型(包括功能的规约和行为的规约)。四、主要研究内容一、领域分析1、基于特征的领域建模1）特征模型建模另外，张伟等人所提出的特征建模过程主要包括服务分析、功能分析、行为特点分析、领域术语分析、共性变化性分析、交互过程分析以及质量需求分析。此过程将不同的特征进行分类，在各层次上识别共性与可变性，因此能够得到一个具有不同关注点的需求模型。四、主要研究内容一、领域分析1、基于特征的领域建模2）特征模型形式化描述和推理

Straeten等使用描述逻辑对特征及特征交互关系进行形式化描述，支持对特征进行推理，并使用系统实现的元级表示方法建立特征模型。

Czarnecki提出了一个基于数量标记的特征模型，并使用UML建立了元模型。四、主要研究内容一、领域分析1、基于特征的领域建模2）特征模型形式化描述和推理也有学者在对特征模型进行扩展的基础上将其转化为约束满足问题，以使用约束编程方法对扩展的特征模型进行形式化描述和自动推理，类似的研究包括使用对象约束语言对特征模型及特征约束关系进行形式化定义等。四、主要研究内容一、领域分析1、基于特征的领域建模2）特征模型形式化描述和推理特征模型通常关注于公共性和可变性分析，Kwanwo等扩展了特征模型进行特征依赖分析，Jaejoon等则从绑定对象、绑定时间和绑定方式三个角度对特征绑定进行分析。四、主要研究内容一、领域分析1、基于特征的领域建模2）特征模型形式化描述和推理进一步的研究包括将特征模型、文法和命题规则结合起来以实现针对特征约束的命题定义，并利用现有工具对特征模型进行调试。这些研究多从某一语义层次针对产品线生命周期特定阶段的特征模型进行形式化描述和推理，适用范围具有一定的局限性，且缺乏统一的形式化描述模型和语言。四、主要研究内容一、领域分析1、基于特征的领域建模3）特征模型应用于产品线工程

Kwanwo等明确了若干概念，并提出了指导性原则。结合基于代理的电子商务系统，Griss系统地提出了一个特征驱动、面向方面的产品线开发方案，该方案构建了一组公共特征和可变特征生产可复用元素，即方面，通过对方面进行组合能够定制生产构件和框架，并最终建立产品线。四、主要研究内容一、领域分析1、基于特征的领域建模3）特征模型应用于产品线工程也有学者通过扩充特征建模技术并采用插拔式(Plug-in)框架建立特征结构和参考体系结构之间的强映射关系实现产品线开发。Kang则提出市场导向的观点，指出面向特征的软件产品线工程开发需要将资产开发和市场紧密联合起来。四、主要研究内容一、领域分析1、基于特征的领域建模3）特征模型应用于产品线工程

Kwanwoo等对FORM方法进行了扩展，通过从四个不同的抽象层次分析应用的可变性并整合对象模型实现产品线的适应性和可复用性。市场导向、特征驱动并结合最新的设计模式和系统框架是这些实现方案的主要特点。四、主要研究内容一、领域分析2、基于目标的需求建模目标(goal)是现实世界中一个或多个参与者(Stakeholder)希望达到和(或)维护的状态。在早期阶段需求工程中，基于目标的模型(目标模型)能够描绘相关参与方的意图并且建立系统与环境的依赖关系，这对于解答需求的“why”问题给出了可视化的解决方案。目标描述语言及建模技术被广泛研究，其中比较著名的技术包括i-Star目标建模框架、Tropos以及KAOS。四、主要研究内容一、领域分析2、基于目标的需求建模

i-Star目标建模框架是一种在早期阶段需求工程中着重描绘软件环境中各参与方意图(intention)的建模方法。该框架使用SR(StrategicRationale)模型表示参与方自己的意图(表现为目标goal、信念belief等)，另外使用SD(StrategicDependency)模型建立参与方意愿间的依赖，推导出能够使得意愿满足的策略。四、主要研究内容一、领域分析2、基于目标的需求建模

Tropos是在i-Star基础上扩展的一种面向智能实体(agent)的建模方法，它将系统目标显式建模在需求模型与系统体系结构设计中，因此为早期阶段的需求工程以及基于agent的软件设计提供支持。四、主要研究内容一、领域分析2、基于目标的需求建模

KAOS则是一种面向目标的需求描述语言，其中对目标、智能体、对象与操作进行了定义。这种需求的规格说明能够在设计阶段被直接实现。四、主要研究内容二、领域设计领域工程分析应用领域的共同特征和可变特征，对刻画这些特征的对象和操作进行选择和抽象，形成领域模型，并进一步生成领域特定的软件体系结构DSSA(Domain-SpecificSoftwareArchitecture)。DSSA是领域工程的核心部分，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。四、主要研究内容二、领域设计

DSSA包含构件以及构件关联的规则，侧重于描述应用系统中的构件组成及接口，说明了系统功能如何在构件间分配。当开发本领域的一个新系统时，可以使用这些构件，并且按照这些规则构成满足当前系统需求的特定系统结构。确定构件的功能语义、类型(公共构件或抽象构件)以及交互关系等，即确定概念体系结构，是DSSA设计的首要任务。四、主要研究内容二、领域设计基于面向对象分析方法的体系结构设计方法没有考虑领域共性和可变性及相关的复用需求，无法应用于DSSA的设计。FORM方法在对基于特征的领域工程和应用工程过程进行系统阐述的基础上，从子系统模型、进程模型和模块模型三个抽象层次给出领域体系结构设计的指导性方针。其中一条原则就是特征模型中的逻辑边界应该对应于体系结构模型中的物理边界，否则，相关的特征需要进一步进行分解或细化。这一原则强调了特征与DSSA中构件建模元素之间的对应关系。其次，“高内聚低藕合”也是一个提及较多的设计准则，例如，具有强数据或控制依赖的特征应该分配到一起以减少通信量等。

四、主要研究内容二、领域设计

PuLSE-DSSA是PuLSE方法的参考体系结构开发组件，它以范围定义和领域模型为输入，前者为产品线开发定义了业务案例，后者则描述了产品线中应用的共性和可变性，输出结果为产品线体系结构。以PuLSE-DSSA为背景，文献对面向单一软件产品的体系结构开发流程和产品线参考体系结构的开发流程进行了对比。四、主要研究内容二、领域设计

NAPLES方案通过分析需求文档等文本资产推导出特定领域潜在的特征和方面及关注点，建立领域体系结构以实现产品线。

Moon在对产品线可变性进行分析的基础上，提出了一种层次性的元模型结构用于开发领域体系结构，但它没有对产品线核心资产之间的依赖关系进行分析，忽视了需求变更对领域体系结构的影响。四、主要研究内容二、领域设计针对现有产品线工程方法研究多集中于软件生命周期早期阶段和抽象层次较高等问题，KobrA方法试图将产品线概念和现有的模型驱动开发等非产品线实现技术整合起来，以降低产品线体系结构开发复杂度。几个典型的产品线领域体系结构设计方法的要点描述如表所示。四、主要研究内容二、领域设计针对现有产品线工程方法研究多集中于软件生命周期早期阶段和抽象层次较高等问题，KobrA方法试图将产品线概念和现有的模型驱动开发等非产品线实现技术整合起来，以降低产品线体系结构开发复杂度。几个典型的产品线领域体系结构设计方法的要点描述如表所示。四、主要研究内容二、领域设计国内刘冬云等针对FORM方法对如何实现从需求到软件体系结构的映射求解过程缺乏明确清晰的描述这一问题，提出了一种面向特征的映射方法，探讨了映射求解过程应遵循的主要原理和步骤，但没有综合考虑特征可变性、绑定时间等方面的因素。四、主要研究内容二、领域设计彭鑫引入本体作为特征模型和领域内业务构件语义的描述基础，提出基于特征模型和构件语义的概念体系结构设计方法，综合考虑了特征模型中的共性、可变性、绑定时间以及结构关系、依赖关系等对DSSA设计的影响，并以构件语义作为特征到概念构件设计的过渡，为特征驱动的领域体系结构设计提供了一种系统的、可自动化的方法支持。该方法主要针对概念体系结构的设计，在实际应用过程中还需要考虑实现技术及部署平台等方面的因素。四、主要研究内容三、构件及构件库设计构件模型研究在高层次上描述和理解构件结构和语义，以作为分析和评价构件的属性和行为的依据。现有的构件模型主要包括构件规格和组装模型(如3C、Wright、JBCOM等)、构件描述与分类模型(如REBOOT、JBCL等)、构件实现模型(如COM/DCOM、CORBA/CCM、JavaBeans)三种类别。统一建模语言(UML)等工具则为构件模型的设计和实现提供了一种工程化的构件语义分析和表示方法。四、主要研究内容三、构件及构件库设计

COMO使用UML作为建模工具，在业务构件设计上主要依据用例/类关系矩阵，按照“高内聚低藕合”的原则进行用例和类的聚集。因此要求在分析阶段获得完整的用例、业务类以及相关的操作定义。O2BC延续了COMO方法的主要思想，在构件建模方法上有所改进，例如将用例/类关系矩阵改为实体/事件交互矩阵并更加强调耦合分析。O2BC以面向对象的领域模型和用例作为输入，输出一组很容易转化为构件设计的逻辑构件。四、主要研究内容三、构件及构件库设计

Teixeira等则在面向对象分析模型的基础上通过几种业务类型聚合规则获得实体构件，同时使用用例模型分析获取过程构件。以上这些方法都是基于面向对象分析模型，没有很好地考虑领域共性和可变性以及相关的复用需求，因此无法应用于产品线领域构件的设计。四、主要研究内容三、构件及构件库设计随着领域工程和产品线研究的深入，基于领域特征模型的可复用构件生产成为新的关注点。KwanwooLee等在特征建模的基础上扩展了特征依赖分析用于产品线构件设计，并在此基础上提出了相应的构件设计指导方针。这些指导原则针对不同的特征依赖类型分别提出，缺少一种综合的体系结构设计方法。而JaejoonLee等则从绑定内容、绑定时间和绑定方式三个方面对特征绑定信息对构件设计的影响进行了分析，对基于绑定时间和灵活性分析的构件设计提供了一些有效的指导原则。四、主要研究内容三、构件及构件库设计与一般的以构件设计实现可变点的观点不同，Rajasree等提出用构件之间的连接器来对可变性进行建模，并认为连接器比构件具有更强的可变性建模能力。这种方法依赖于基于框架和设计模式的复用方法，即使用设计模式来刻画框架中的扩展点，并用模式图来表示可变点对其它部分的影响。这种方法缺少与需求规格说明之间的追踪关系。四、主要研究内容三、构件及构件库设计为按需定制软件系统，需要从构件库中选取恰当的构件，并对这些构件进行各种修改，进而将其组装为需求业务模型。REBOOT、NATO、北大青鸟等基于刻面的检索方式实现构件选取，技术上以传统的数据库检索技术为主，并结合利用同义词词典和刻面术语间的层次结构来实现构件的松弛匹配。四、主要研究内容三、构件及构件库设计借鉴有关树匹配方面的研究成果，国内王渊峰等通过将构件描述与需求模型间的匹配问题转化为构件的刻面描述树与需求模型的刻面描述树的树形结构化描述之间的匹配，但其中对于树包含的算法只考虑了枚举算法，影响了搜索效率。同时，由于构件的非绝对标准化，有学者使用逻辑谓词定义了接口更改、构件组合和构件监控等构件行为调整方式对选取的构件进行修改，以满足具体应用需求，但在可操作性上存在一定的问题。四、主要研究内容三、构件及构件库设计除此之外，还有不少学者通过建立构件交互矩阵、构造基于业务策略的构件设计模型和建立形式化构件优化框架等方法对构件优化技术进行了研究。四、主要研究内容三、构件及构件库设计在构件库方面，国内北大JBCL系统以青鸟构件模型为基础，建立青鸟构件库数据模型，并与其他CASE工具相结合，支持构件的生产和描述，实现了一个支持对可复用构件进行度量、检索和访问控制操作的构件库，以满足基于“构件-框架”复用的软件开发过程的需要。四、主要研究内容四、可变性分析与管理软件产品线的所有产品共用公共软件资产，同时每个产品拥有各自特定的结构、功能或代码，领域产品家族产品间的差异性体现了软件产品线的可变性。四、主要研究内容四、可变性分析与管理诸多研究学者从特征模型和领域体系结构角度对可变性进行了分析。有文献对产品线可变性进行了分类，分别讨论了它们对产品线体系结构的影响，并提出了一种基于模式的产品线体系结构及相关的模式语言对可变性进行管理，但该方法缺乏清晰的过程模型，不能支持基于模式的产品线重复开发。四、主要研究内容四、可变性分析与管理

Goedicke等从基于构件封装对象间接描述产品线体系结构和使用消息重定向动态组合及定制具体产品所需的构件两个角度研究了领域特定体系结构的运行时动态可变性，但它没有对可变点的动态绑定对运行时效率的影响进行分析。四、主要研究内容四、可变性分析与管理另有文献对软件体系结构中的可变性类型进行了描述，并对在开发过程中体系结构何时进行调整进行了分析。上述研究侧重于定性分析，为此Thomas等将特征模型的可变化程度定义为其实例化能够得到的有效产品特征模型的数目，并在对不同可变类型和特征依赖关系进行分析的基础上提出了一种计算产品线可变程度的方法。以上方法均没有考虑特征实现方案，即软件资产的可选性对可变性带来的影响。四、主要研究内容四、可变性分析与管理在可变性描述和建模方面，webber等提出一种变异点模型，通过参数化、信息隐藏、继承和变异点四种方式对软件产品线的变化性进行建模，该建模方案的不足之处在于在决定变量是作为公共部分还是独属于具体应用存在时需要进行额外的处理。可变特征的不确定性决定了产品线的可变性，特征驱动的变化性被视为关注点多维分离的一个实例，并通过横切的异构实体，即特征变异关注点进行表达，但其对新引入的软件制品类型支持不够。四、主要研究内容四、可变性分析与管理

COVAMOF框架模型试图在所有抽象层次为软件产品家族提供统一的可变性建模方案，该框架允许对变异点之间复杂的依赖关系进行一阶表示，同时支持对依赖之间的关系进行建模。文献基于变异点的引入和绑定时间所对应的软件开发生命周期阶段，提出了一种系统无关的方式形式化表示可变性。四、主要研究内容四、可变性分析与管理

RafaelCapilla等基于扩展的FODA树，通过为服务参数和系统属性增加数值等语义信息描述软件系统的可变性，但如何通过领域分析获取扩展的FODA树在文中未作描述。Bachrnann等为在产品线开发过程中引入可变性变量提出了一种统一的元模型，能够显式地对不同阶段引入的可变性之间的依赖关系进行表示。文献从需求、设计、实现及工具支持等方面对产品线的可变性建模方法进行了总结和讨论。四、主要研究内容四、可变性分析与管理可变性管理涉及到软件产品线开发生命周期的所有阶段，在领域工程阶段，变异点被引入，而在应用工程阶段，变异点被绑定到实际选取的变量。HassanGomaa等提出使用UML从多个视图为可变性管理建立元模型及一致性校验规则。文献则从软件配置管理的角度，从变异类型和软件实体粒度两个维度将软件产品线的变体管理分解为九个子区间进行分析，并分别提出技术解决方案。但在实际应用过程中，要实现将问题明确归于某一子区间存在一定难度。四、主要研究内容四、可变性分析与管理

Caesar语言结合面向特征和面向方面两种方案，支持多路提取模块和连接拦截，以解决可变性管理中的横切模块化问题。该语言是否适用于大型系统仍有待验证。还有学者提出基于UML的可变性管理流程，允许对产品线可变性及其实现进行确认、表示和界定。四、主要研究内容四、可变性分析与管理除此之外，还有一些学者在可变性对产品线开发的影响等方面展开了深入的研究。SteffenThiel等提出将可变性和产品线体系结构设计进行整合，使可变性提升为体系结构的驱动，并将可变性需求嵌入到体系结构设计框架中。HongyuZhang等则基于框架技术提出了一种基于XML的变量配置语言XVCL用于对产品线中的变量进行操作和处理。产品线资产使用XVCL进行开发形成框架，通过对框架进行调整和组合即可得到特定的系统和资产组成。四、主要研究内容五、产品线进化与再工程随着用户需求和业务规则的不断变化以及技术的不断发展，需要不断地对软件产品线进行重构和进化，如何对进化过程进行管理并维持产品线的一致性成为产品线研究急待解决的一个问题。四、主要研究内容五、产品线进化与再工程

Bosch等率先对产品家族的进化进行了分类，并对体系结构进化可能带来的影响进行了讨论。产品线各类软件资产之间的互依赖关系导致软件产品线的进化过程进一步复杂化。svahnberg等将产品线进化细化为需求进化、软件体系结构进化和构件进化等类型，并在分析这些进化类型的相互关系的基础上，提出了若干指导性原则以支持软件资产进化。文献以面向移动电话软件系统的产品线为例，对产品线的连续进化和不连续进化方式进行了分析。四、主要研究内容五、产品线进化与再工程就如何消除不确定因素对产品线进化的影响这一问题，文献基于模型驱动的软件产品线，通过案例分析，举例说明了结构化的模型转换如何通过自动转化领域模型以维持领域进化的稳定性，以及面向方面的模型转换如何通过捕获基于模型的结构关注减少参与人员的工作，为降低未知需求对产品线进化的影响提供了有益的指导。四、主要研究内容五、产品线进化与再工程为避免新需求的不断加入而导致产品线体系结构恶化，Riebisch等提出了一种进化开发流程，通过将依赖和回溯信息整合到产品线开发流程，支持产品线的自动重构和更改。文献则提出将面向方面编程和框架技术结合起来，支持横切本地关注点，以提高系统的可理解性，解决产品线进化过程中不可预知的需求场景带来的问题。四、主要研究内容五、产品线进化与再工程在资产管理和过程控制方面，ChangHwan等就产品线进化过程中如何实现特征模型的同步这一问题进行了研究，并提出了解决方案，但未解决特征模型处于分布式状态时的同步问题。文献使用两种类型的文档分别描述产品家族的参考体系结构和配置体系结构，以实现对遗留产品家族体系结构的描述和进化管理。Taborda提出市场模式描述产品线开发参与者之间的交互关系，并引入发布矩阵技术为产品线开发控制计划，以整理和记录产品线的进化情况。该方法在复杂复用背景下同样适用，但相关概念未能进一步扩展为抽象模型。四、主要研究内容五、产品线进化与再工程另一方面，部分遗留产品线将逐渐退出使用，如何对这些系统进行挖掘、整理和维护，以充分利用可复用资产成为产品线工程面临的一大难题。产品线再工程是解决这些问题的主要技术手段。四、主要研究内容五、产品线进化与再工程在遗留资产挖掘方面，文献使用软件体系结构描述语言对构件封装所需属性进行描述，在此基础上引入适配器设计模式实现遗留资产的迁移。但该方案建立在特定的假设前提之上，实际应用起来具有一定的局限性。Johnson描述了一种工具集体系结构，支持对已有的工具进行定位、对比和评估，以实现从遗留系统中挖掘业务构件。该方案功能的有效发挥有赖于资产挖掘工具的完善。四、主要研究内容五、产品线进化与再工程在特征模型和领域体系结构重构方面，文献通过逆向工程恢复遗留应用的体系结构和构件，并在此基础上进一步重新构造特征模型，基于这些领域重构资产即可为应用设计新的体系结构和构件。四、主要研究内容五、产品线进化与再工程如何处理特征依赖及交互也是产品线再工程过程中的一个重要问题，StefnFerber等引入依赖分析建模技术对特征依赖及交互进行形式化表示，支持对遗留产品线规范和实现进行特征再工程和产品线配置定义。RE-PLACE方案充分考虑了可预期的新的系统变量，支持将遗留软件资产转换为产品线体系结构，但其实施步骤较为繁琐。四、主要研究内容五、产品线进化与再工程

Smith等则提出了一种系统的、以体系结构为中心的选择分析再工程方法，根据产品线构件需求对遗留构件进行挖掘，以构建产品线或新的软件体系结构。遗留构件的选取与否建立在对其重构代价进行评估的基础上。四、主要研究内容六、产品线评估与测试软件体系结构评估技术可以分为两类，分别为询问技术(定性评估)和测量技术(定量评估)。询问技术包括场景、调查表和清单等，如D-SAAM方法引入具体场景和移动场景，以缩小参考体系结构和场景之间的间隙，其中具体场景无需改变产品线体系结构即可实现，而移动场景可以通过得到的产品实现；测量技术则包括仿真、原型、试验和数学模拟等，如用于评定和提高产品线体系结构的服务利用衡量标准，以及由基于构件的测量方法调整而来对产品线体系结构进行结构评定的Rahman衡量标准等。询问技术被用于评估操作或开发品质，测量技术则用于评测特定的操作性质。

四、主要研究内容六、产品线评估与测试在领域相关的质量属性评估方面，Alonso等使用RMA模型评估实时系统领域产品家族的时间属性。DeLange等提出一种产品线体系结构原型方案，对复杂度、性能需求等问题进行评测。而在功能需求评估方面则主要使用模型检测、定理证明、证据检验、等价检查等技术。功能性需求或公共行为可以使用自动化工具进行分析，而产品线质量属性则主要依靠手动分析技术。四、主要研究内容六、产品线评估与测试有多种方法可用于在设计阶段对产品线体系结构进行评估。例如，用于评估信息系统产品家族体系结构的FAAM方法，用于分析产品线体系结构质量