扩展方面机制的软件产品线体系结构建模及构件组装实现

*)基金项目：国家863计划(No.2007AA01Z125;No.2006AA01Z189)；国家自然科学基金(No.60703092).扩展方面机制的软件产品线体系结构建模及构件组装实现沈立炜，彭鑫，赵文耘（复旦大学计算机科学技术学院软件工程实验室上海200433）摘要：软件产品线是提高软件开发效率与质量的有效途径，它以体系结构(SA)为蓝图，定义组成产品线的构件与构件之间相互作用的关系，指导基于构件的应用产品组装实现。现有的基于接口连接式的体系结构仅能描述构件间的直接交互，却无法支持产品线可变性所带来的更为复杂的构件交互情况。因此，本文提出一种扩展方面机制的软件产品线体系结构建模及构件组装实现方法，其核心是一套扩展xADL2.0、结合面向方面机制的软件产品线体系结构描述语言。它能支持基于可变性的产品线体系结构设计与定制，并指导应用产品的构件组装过程。在此方法的基础上，我们开发了原型工具FdSPLC，提供对体系结构的可视化建模以及应用产品的自动化生成。关键词：软件产品线开发；软件体系结构；构件组装；构件交互模式中图分类号：TP311文献标识码：A文章编号：0372-2112SoftwareProductLineArchitectureModelingandComponentCompositionImplementationwithExtensionofAspectualMechanismSHENLi-wei,PENGXin,ZHAOWen-yun(SchoolofComputerScience,FudanUniversity,Shanghai200433,China)Abstract:Softwareproductline(SPL)canincreasetheefficiencyandqualityofsoftwaredevelopment.Softwarearchitecture(SA),astheblueprintofSPL,definestheinter-relationshipsbetweencomponentsandguidesthecomponentcompositionimplementation.However,theexistinginterfaceconnectionarchitectureislimitedtodescribethedirectinteractionsbetweencomponents.ItcannotsupportthemorecomplexinteractionsituationswhichemergewiththeSPLvariability.Inthispaper,weproposeamethodofsoftwareproductlinearchitecturemodelingandcomponentcompositionimplementationwithextensionofaspectualmechanism.Thecoreisanarchitecturedescriptionlanguage(ADL)whichextendsxADL2.0andcombineswithaspect-orientedtechniques.TheADLsupportsthedesignandcustomizationforSPLarchitecturebasedonvariability,andinstructsthecomponentcompositionprocessforapplications.Furthermore,wehavedevelopedaprototypetoolFdSPLCwhichprovidesthevisualmodelingofarchitectureaswellastheautomaticapplicationderivation.Keywords:Softwareproductlinedevelopment;Softwarearchitecture;Componentcomposition;Componentinteractionstyle1概述在以构件为基本单元的软件产品线中，体系结构作为整个开发过程的蓝图，定义了组成产品线的构件与构件之间的相互作用关系[1]，它包括领域体系结构(DSSA)与应用体系结构(ASSA)：DSSA是领域工程的制品，描述了所有应用系统的共性与差异性，而ASSA则是在应用工程阶段由前者定制、裁剪得来。软件体系结构为构件的集成组装提供了基础和上下文[2]，文献[3]比较了三种不同类型的体系结构，包括对象连接式、接口连接式与插头插座式。其中，接口连接式体系结构通过接口定义系统中构件之间的所有连接，匹配所要求的功能和所提供的功能，因此降低了构件之间的依赖性，提高了构件的独立性和可复用性[4]。这种灵活的连接方式有利于软件产品线的设计与组装，尤其对于具有实现变体的构件而言，在体系结构设计时即可通过接口建立构件之间的关联关系，然后在组装实现时确定符合接口描述的构件实现体。软件产品线的DSSA含有可变性，与单系统的体系结构相比较，它包含更为多样的构件交互情况。其中，某些构件交互无法用接口连接式的体系结构描述，因此，我们仍然需要系统化的方法支持软件产品线体系结构的建模，同时指导自动化的应用产品生成。针对以上需求，本文提出了一种扩展方面机制的软件产品线体系结构建模及构件组装实现方法，其核心是一套扩展xADL2.0[7]、结合面向方面机制的软件产品线体系结构描述语言。它包括对不同构件交互类型的定义，支持基于可变性的产品线体系结构设计与定制，并指导应用产品的构件组装过程。在此方法的基础上，我们开发了原型工具FdSPLC。它提供对体系结构的可视化建模，另外支持应用产品的自动化生成。本文剩余结构如下：第2节是背景介绍，分析产品线实现所存在的问题。第3节介绍扩展xADL2.0的产品线体系结构建模技术，包括对不同构件交互模式的定义。在第4节中基于产品线体系结构的应用产品组装将被介绍，包括构件交互模式的实现过程。第5节是原型工具FdSPLC的简要介绍。最后是总结以及对未来工作的展望。2背景介绍2.1产品线体系结构可变性是软件产品线研究的核心，它将产品线的DSSA划分为基础部分与可变部分。基础部分提供的功能(基础程序)是被所有应用产品所共享的；而可变部分的功能代表了应用产品之间的差异性。一般而言，可变部分是对基础部分功能的扩展，根据应用需求决定是否附加到基础程序上去。DSSA中构件的可变性分为Optional、Alternative与Abstract三种类型：Optional表示可选构件，即应用系统体系结构中可以包括该构件也可以移除该构件；Alternative表示多选一构件，即DSSA中为某一构件提供了多个实现变体，应用系统体系结构可以从中选择一个；Abstract表示抽象构件，即以占位符的形式存在于DSSA中且没有提供任何实现变体的构件，抽象构件的具体实现将在应用系统开发时提供。体系结构描述语言(ADL)负责软件体系结构的描述、分析与重用[5]。对于软件产品线，ADL必须明确描述DSSA中构件的可变性。国内外已有很多工作关注于产品线的ADL，其中xADL2.0[7]是一种高度可扩展的、基于XML的体系结构描述语言，通过一组Schema支持产品线体系结构的建模。Structure&TypeSchema是xADL2.0中最重要的部分，它用来描述产品线设计时(design-time)的基本元素，包括构件(component)、连接器(connector)以及关联(link)。体系结构中的每一个构件能被指派一个构件类型(componentType)，构件类型定义了构件的类型信息，例如型构(signature)等。Options和VariantsSchema用来定义产品线体系结构的可变性。其中OptionsSchema表示Optional可变性，而VariantsSchema能够支持Alternative与Abstract可变性的描述(如果variant构件至少包含一个变体，它具有Alternative可变性；如果不包含任何变体，则其具有Abstract可变性)。每个Optional或者Alternative变体元素都伴随一个Guard条件。当条件被满足时，Optional元素或Alternative的变体元素将被包含在体系结构中。另外，Alternative构件的变体之间具有互斥的Guard条件，表示在同一时刻至多有一个变体被选择。xADL2.0的详细描述可参见文献[7]。2.2产品线实现问题分析在本小节中，我们以简化的图书馆管理系统产品线实例来分析现有的基于接口连接式体系结构的不足。图1是该产品线的初始体系结构图。其中，LibraryMainForm是系统的主界面，通过它可以进入借书界面(BorrowBookForm)与还书界面(ReturnBookForm)。借书、还书的过程都将与图书信息管理(BookManage)和读者借阅记录管理(ReaderRecordManage)的功能交互。还书的流程还包括罚金计算与收取，其支付模式具有Alternative可变性，变体分别为现金支付(PenaltyByCash)与学生卡支付(PenaltyByStudentCard)。另外，记录日志(Log)、获取图片(getImage)与图书图片显示(BookPicShow，表示借书界面是否显示图书封面图片，它将使用获取图片功能)是Optional的功能，它们依照应用需求被包含进或排除出实际系统。图1图书馆管理系统产品线初始体系结构当采用接口连接式体系结构建模时，将出现以下不适合描述或无法描述的情况：(1)不适合描述更改执行流程的构件交互。Optional可变性会影响系统的执行流程(如果Log被选定，借书或还书的执行过程将会包含对Log的调用，反之则不包含)。从实现的角度看，接口连接式的体系结构要求与Optional功能连接的构件必须包含与其交互的接口，同时对接口的控制必须在构件内部实现(Optional功能选定时使用此接口，否则取消使用)。一般而言，可以通过条件判断语句(if/else)进行控制，但它会对构件实现提出很高的要求，也不利于构件的复用。(2)不适合描述需求的分散特性。产品线的需求被分解为责任(responsibility)[6]，这些责任分散在不同的实现中(图书图片显示功能被分解为图片框ImageContainer与BookManage构件的getImage功能)。接口连接式体系结构中的构件一般表示单个需求的功能，因此它不适合表达具有分散特性的需求。(3)无法描述体系结构中Optional资源。图片框ImageContainer作为完成Optional功能“图书图片显示”的资源角色(resourcerole)[9]，需要被加入借书界面中。在这种情况下，资源也具有Optional可变性。我们把资源看作构件，但它与目标构件之间的交互关系无法用接口连接的方式描述。2.3AOP在产品线开发中的应用AOP技术大大提高了软件开发的模块化(尤其是针对横切方面)程度[8]，而这一改进主要源于AOP中方面的两大特性：多量化(Quantification)和不知觉性(Obliviousness)。目前对于AOP技术的应用一般都强调它对横切关注点的支持能力(通过多量化特性)，但AOP的“不知觉”却为构件的交互提供了有效的帮助。对于更改执行流程的构件交互，采用AOP在不影响基础程序的情况下，将Optional的功能编织到基础程序上是一种理想的解决方案；另外，对于Optional的资源交互，AOP的Introduction机制能够将资源插装到目标构件中，而不需更改目标构件的实现。在我们的前期工作[9]中，我们通过AOP实现应用产品生成。在本文的方法中，我们将以接口连接式的体系结构为主体，结合面向方面的机制支持产品线的描述与开发。3扩展xADL2.0的产品线体系结构建模3.1产