基于软件库的软件生产线模型研究

金星波

(中国人民解放军92493部队，辽宁葫芦岛125000)

0 引 言

关于软件生产线(SPL:Software-Product Line)的研究最早可追溯至上个世纪70年代初，David［1］对程序家族进行了研究，但软件生产线的实际应用始于上个世纪80年代中期，并在一些项目上取得了成功。其中瑞士CelsiusTech公司从军方获取舰艇防御系统的研制项目，利用产品线技术，同时进行了两个舰艇的防御系统开发，使系统开发时间大大缩短，(从9年降低至3年);并大大降低软件开发费用，系统软硬件费用比由65∶35下降到20∶80［2］。

从20世纪90年代，学者开始对软件生产线的理论系统进行研究，当时主要的研究对象都是一些实例，从实例分析中建立生产线的理论模型。从此对软件生产线的理论研究以及实际系统的研制一直都是软件工程中的焦点，其发展非常迅猛，最具代表性的的卡内基梅隆大学软件工程学院(SEI)的研究，如诺基亚的生产即采用了SEI的技术。直到目前，仍有很多学者对软件生产线进行研究，如Thum等［3］对特征模型进行了探讨，Vierhauser等［4］对软件生产线模型以及支持工具进行了研究。

国内也有许多学者对生产线技术进行了研究，并对软件生产线的关键技术以及建模方法进行了深入的探讨［5-7］。虽然生产技术已日趋成熟，但仍有缺陷。笔者针对该缺陷，提出过程模型和迁移模型。并根据该模型建立模拟系统。经实例验证，该模型可以解决软件生产线初期投入大且迁移困难的问题。

1 软件生产线理论简述

1.1 软件生产线的定义

许多学者从不同角度出发，对软件生产线给出了多种定义。如Weiss等［8］提出将利用产品之间的共同部分，并提前对产品的可变性进行充分考虑的产品家族定义为生产线;Margaret［9］提出生产线是由多个系统构成的软件家族，这些系统在功能方面及组成的元素方面具有共性(communalities)，并具有个性(variabilities)，系统间有一定的相似性。这些定义都从一定角度描述了生产线的特征，也都非常经典，但笔者更倾向于卡内基梅隆大学软件工程学院的定义，它更全面、准确的描述了软件生产线的主要基本特性。

软件生产线是多个软件密集系统组成的集合，这些系统共享一个公共的、可管理的特征集，该特征集能满足选定的市场或任务领域的特定需求，这些系统遵循一个预描述的方式，在公共的核心资源(core assets)基础上开发的。

1.2 STARS双生命周期经典模型

STARS最早提出了生产线的理论模型［10］，该模型将生产线的生产过程分成两个相互交叉的生命周期，分别命名为领域工程部分以及应用工程部分。领域工程部分分为领域分析、领域设计和领域实现3个阶段;相似的，应用工程部分也分为需求分析、系统设计及系统实现3个阶段。图1给出了该模型。

图1 STARS软件生产线双周期生命模型Fig.1 STARS model of double life cycle of SPL

SRARS模型定义了经典的软件生产线的开发过程与进化方式，当前有许多生产线的开发模型都是基于此设计的。

2 软件生产线缺陷分析及应对策略

2.1 目前软件生产线存在的缺陷

经过多年的发展，软件生产线技术已经越来越成熟，但始终有部分缺陷未能克服。

1)大部分生产线技术都是依托SRARS模型或其发展进化生成的模型，如此软件生产线的开发多数都分为两个开发团队(卡梅隆模型则分为3个团队，多了一个管理团队):核心资源(Core Assets)团队、应用工程(Application Engineering)团队。应用工程团队的开发人员要利用核心资源，针对特定的产品，分析其结构，并手工去除在核心资源的代码中粘贴特定产品的代码，或反之;由于人与人之间是有差别的，这就难以保证代码的统一，并且安全性上也无法保证。另外，一个软件生产线的产品有可能多，产品越多，应用工程的团队也会越大，带来的问题也会越来越多。

2)一个生产线上的产品在对核心资源进行复用时，往往有自己的上下文。有时，这些在应用工程中的成果应该充实到核心资源中，但因其独特的环境因素，往往很难实现。这就导致在生产线对多个产品进行生产时，只能为每个单独的产品编写它单独的代码，降低了生产线的实用价值。

3)在一个软件生产线的生产过程中往往有两个单独的团队，这会导致若产品出现了偏差，很难辨别是哪个团队出现了问题。为了改善此问题，SEI的生产线生命模型增加了一个管理团队协调工作，但在实际生产过程中还是很容易出现团队间的矛盾，互相推卸责任，导致开发效率的降低。

4)开发产品时使用生产线技术，不论是资金、人员以及时间，初期都需要较大的投入，而且在采用生产线技术时，往往第1个产品的出现时间要远远长于采用非产品线技术开发所得，即这些投入可能短时间得不到任何回报。因此除了技术上的原因，这也是中小型公司较少采用生产线技术进行产品开发的重要原因之一。

5)随着一个生产线技术在实践中的不断应用，其核心资源也在一步步的扩张，其复杂程度也是越来越高，不论生产线的维护还是它的扩展都需要越来越多的费用，以至最后难以维持。这也导致一个生产线利用另一个生产线的资源难以实现，想把一个生产线的核心资源迁移至另一个生产线其难度则更大。

2.2 生产线缺陷分析以及相应的对案研究

以上讨论了软件生产线的相关缺陷，现对其进行分析。

1)对于实际应用于工业上的生产线，如汽车生产线，其开发上没有两个独立的团队，生产一辆汽车并不需要工人去做生产线的再次开发工作。这也给予软件生产线一个提示，若一个软件生产线没有应用工程开发团队，而只有一个唯一的开发团队(核心资源团队)，缺陷1)～3)都已不存在。所以笔者认为，应用工程团队应给予取消，即核心资源应该可以直接对产品进行开发。

2)对于缺陷4)，即初期投资庞大是生产线实际应用的一个重大限制，尤其对中小型的软件公司。其产生的原因主要有两点:①生产线的开发不同于一个单独产品的开发，要经过多个领域专家对整个领域进行分析建立产品集的领域模型，而且还要考虑产品未来各种可能的发展方向;②核心资源的目的之一即是要为复用服务，其编写时自然多了很多的限制条件，这也增加了代码编写的复杂程度。针对这两个原因，如果:①领域模型的变化并不会导致软件有较大的变化;②代码在缩写时能遵守一定的即定规则，就可满足被复用的条件。那么这两个问题将会得到很大程度的弱化。

3)针对缺陷5)，数据库技术是此缺陷的天然解决方案，把软件依不同级别的复用粒度分别放在数据库中，而关系数据库其强大的组织以及检索功能，恰恰可为生产线的维护以及迁移提供强大的支持。

3 软件生产线过程、迁移模型以及一个实例

基于以上分析，笔者提出了两个模型:软件生产线过程模型和软件生产线无缝迁移模型。二者间关系密切，此软件生产线过程模型在很大程度上考虑到迁移问题，是为了尽可能简单地复用以往的资源，如代码、模块等;而迁移后生产线的资源也可以很容易归并至软件库中，与之前的资源一起可以为下一个迁移所利用。

3.1 软件生产线过程模型

软件生产线的过程模型如图2所示。

图2 软件生产线过程模型Fig.2 A process model of SPL

1)软件库分为4层。

基础库层:位于软件库的最底层，由开发语言本身提供的类库与COST构件库组成。

自定义类库层:建立在基础库上，存储依据实际需要建立的类。

模块库层:存储相互独立、可组装的模块。

模板库层:存储模板，提供的是类似于配置器的程序，通过模板即可生产出所需产品。

2)生产线建立流程。

①进行领域分析，建立领域模型。领域模型的建立应尽可能全面覆盖领域范畴，采用大规模软件定制的策略，充分考虑生产线的可扩展性与可裁剪性。但可以只开发与当前产品相关的模块及代码。

②将领域模型转化为AO树特征模型。

③依据AO树特征模型划分功能模块。本步骤与②是为了方便将领域模型转化为计算机实现，实现的方法并不限于AO树。

④依据需求建立需要的自定义类。在此如何去建立需要的类也可以根据自身状况灵活掌握，可以采用面向对象的方法，也可以采用面向方面的方法，但必须将此类继承自何类或引用或使用的方法必须标注在数据表中。

⑤建立模块。与④相同，也须将本模块包含的类标注在数据表中。

⑥组织模板，软件生产线建成。

3.2 软件生产线无缝迁移模型

依据上述软件生产线过程模型建立生产线，则生产线的维护及迁移问题就转化为软件库中数据的转移问题。模型如图3所示。

图3 软件生产线无缝迁移模型Fig.3 A seamless migration model of SPL

从原软件库向新软件库转移时，仍应遵循自项而下的模式，首先对新的领域进行分析，建立领域模型，建立AO特征模型。然后依据AO模型先从原软件库中提取可用的模块，提取可用的自定义类，在提取模块时须能同进提取此模块所涉及至的自定义类及COTS构件，提取自定义类时亦如此。此后新生产线的建立依前述生产线过程模型建立即可。

3.3 实例

依托软件生产线过程模型，笔者建立了一个车载多媒体模拟系统。系统包括领域分析过程、形式化过程、AO模型建立过程等，并在SQL Server之上建立了系统的支持工具，详细情况见文献［10］。系统可以根据用户的选择自动生成所需要的产品。生产线的建立并不比生产一个产品复杂多少，而且因为关系数据库的作用可以相对容易剥离出较大粒度的复用，利于生产线的迁移。

4 结 语

在研究了软件产品线的概念、相关方法的基础上，深入分析了当前软件产品线方法的一些不足之处，并提出了相应的对策。在此基础上，笔者提出软件生产线过程模型及无缝迁移模型。这两个模型可以有效降低生产线的初期投入，并对日后的迁移建立了基础，具有一定的实用价值以及推广价值。

［1］DAVID PARNAS.On the Criteria to be Used in Decomposing Systems into Modules［C］∥Communication of the ACM.［S.l.］:ACM，1972:1053-1058.

［2］LISA BROWNSWORD，PAUL CLEMENTS.A Case Study in Sueeessful Produet Line Development［R］.［S.l.］:Software Engineering Institute，Carnegie Mellon University，1996，10.

［3］THUM T，BATORY D，KASTNER C.Reasoning about Rdits to Feature Models［C］∥Software Engineering，2009.ICSE 2009.IEEE 31st International Conference on.Vancouver，Canada:IEEE，2009:254-264.

［4］VIERHAUSER M，HOLL G，RABISER R.A Deployment Infrastructure for Product Line Models and Tools［C］∥Software Product Line Conference(SPLC)，2011 15th International.Munich，Germany:IEEE，2011:287-294.

［5］聂坤明，张莉，樊志强.软件产品线可变性建模技术系统综述［J］.软件学报，2013，24(9):2001-2019.NIE Kunming，ZHANG Li，FAN Zhiqiang.Systematic Literature Review of Software Product Line Variability Modeling Techniques［J］.Journal of Software，2013，24(9):2001-2019.

［6］孙连山，王今雨.一种面向特征的软件产品线非功能需求建模方法［J］.计算机工程与科学，2013，39(5):67-76.SUN Lianshan，WANG Jinyu.A Feature-Oriented Approach to Modeling Non-Functional Requirements in Software Prodect Line［J］.Computer Engineering＆ Science，2013，39(5):67-76.

［7］赵卓，吴慧玲.基于复用的软件产品线工程关键技术研究［J］.计算机与数字工程，2013，41(12):2012-2015.ZHAO Zhuo，WU Huiling.Towards Software Reuse and Its Applications in Software Product Line Engineering［J］.Computer＆ Digital Engineering，2013，41(12):2012-2015.

［8］WEISS DAVID M，CHI TAU LAI.Software Product-Line Engineering:A Family-Based Software Development Approach［J］.Addison-Wesley，1999，41(3):49-56.

［9］MARGARET J DAVIS.Reengineering and the Product Line Approach to Software Development［J］.Boeing Defense＆ Space Group，1995，29(4):128-131.

［10］金星波.软件产品线方法研究及在嵌入式软件开发中的应用［D］.长春:吉林大学计算机科学与技术学院，2011.JIN Xingbo.Research Software Production Line and Its Application in hte Embedded Software Development［D］.Changchun:College of Computer Science and Technology，Jilin University，2011.