1 引言
1.1 基本概念
复用概念的第一次引入是在1968年NATO软件工程会议上McIlroy的论文”大量生产的软件构件”中
.在此以前,子程序的概念也体现了复用的思想.但其目的是为了节省当时昂贵的机器内存资源,并不是为了节省开发软件所需的人力资源.然而子程序的概念可以用于节省人力资源的目的,从而出现了通用子程序库,供程序员在编程时使用.例如,数学程序库就是非常成功的子程序复用的例子.
在其后的发展过程中,有许多复用技术的研究成果和成功的复用实践活动.但是,复用技术在整体上对软件产业的影响却并不尽如人意.
这是由于技术方面和非技术方面的种种因素造成的,其中技术上的不成熟是一个主要原因.近十几年来,面向对象技术出现并逐步成为主流技术,为软件复用提供了基本的技术支持.软件复用研究重新成为热点,被视为解决软件危机,提高软件生产效率和质量的现实可行的途径 [Mili 95].
软件复用是指重复使用”为了复用目的而设计的软件”的过程 [Tracz 95].
相应地,可复用软件是指为了复用目的而设计的软件.与软件复用的概念相关,重复使用软件的行为还可能是重复使用”并非为了复用目的而设计的软件”的过程,或在一个应用系统的不同版本间重复使用代码的过程,这两类行为都不属于严格意义上的软件复用.
在软件演化的过程中,重复使用的行为可能发生在三个维上:
时间维:使用以前的软件版本作为新版本的基础,加入新功能,适应新需求,即软件维护.
平台维:以某平台上的软件为基础,修改其和运行平台相关的部分,使其运行于新平台,即软件移植.
应用维:将某软件(或其中构件)用于其他应用系统中,新系统具有不同功能和用途,即真正的软件复用.
这三种行为中都重复使用了现有的软件,
但是,真正的复用是为了支持软件在应用维的演化,使用”为复用而开发的软件(构件)”来更快,更好地开发新的应用系统.
分析传统产业的发展,其基本模式均是符合标准的零部件(构件)生产以及基于标准构件的产品生产(组装),其中,
构件是核心和基础,”复用”是必需的手段.
实践表明,这种模式是产业工程化,工业化的必由之路.标准零部件生产业的独立存在和发展是产业形成规模经济的前提.机械,建筑等传统行业以及年轻的计算机硬件产业的成功发展均是基于这种模式并充分证明了这种模式的可行性和正确性.这种模式是软件产业发展的良好借鉴,软件产业要发展并形成规模经济,标准构件的生产和构件的复用是关键因素.这正是软件复用受到高度重视的根本原因.
软件复用可以从多个角度进行考察 [Prieto-Diaz 93].依据复用的对象,可以将软件复用分为产品复用和过程复用.
产品复用指复用已有的软件构件,通过构件集成(组装)得到新系统.过程复用指复用已有的软件开发过程,使用可复用的应用生成器来自动或半自动地生成所需系统.
过程复用依赖于软件自动化技术的发展
,目前只适用于一些特殊的应用领域.
产品复用是目前现实的,主流的途径.
依据对可复用信息进行复用的方式,可以将软件复用区分为
黑盒(Black-box)复用和白盒(White-box)复用
.黑盒复用指对已有构件不需作任何修改,直接进行复用.这是理想的复用方式.白盒复用指已有构件并不能完全符合用户需求,需要根据用户需求进行适应性修改后才可使用.而在大多数应用的组装过程中,构件的适应性修改是必需的.
1.2 复用意义
通常情况下,
应用软件系统的开发过程包含以下几个阶段:需求分析,设计,编码,测试,维护等
.当每个应用系统的开发都是从头开始时,在系统开发过程中就必然存在大量的重复劳动,如:用户需求获取的重复,需求分析和设计的重复,编码的重复,测试的重复和文档工作的重复等.
探讨应用系统的本质,可以发现其中通常包含三类成分:①通用基本构件:是特定于计算机系统的构成成分,如基本的数据结构,用户界面元素等,它们可以存在于各种应用系统中;②领域共性构件:是应用系统所属领域的共性构成成分,它们存在于该领域的各个应用系统中;③应用专用构件:是每个应用系统的特有构成成分.
应用系统开发中的重复劳动主要在于前两类构成成分的重复开发.
软件复用是在软件开发中避免重复劳动的解决方案,其出发点是应用系统的开发不再采用一切”从零开始”的模式,而是以已有的工作为基础,充分利用过去应用系统开发中积累的知识和经验,如:需求分析结果,设计方案,源代码,测试计划及测试案例等,从而将开发的重点集中于应用的特有构成成分.
通过软件复用,在应用系统开发中可以充分地利用已有的开发成果,消除了包括分析,设计,编码,测试等在内的许多重复劳动,从而提高了软件开发的效率,同时,通过复用高质量的已有开发成果,避免了重新开发可能引入的错误,从而提高了软件的质量.
1.3 关键因素
软件复用有三个基本问题,一是必须有可以复用的对象,二是所复用的对象必须是有用的,三是复用者需要知道如何去使用被复用的对象
.软件复用包括两个相关的过程:
可复用软件(构件)的开发(Development for Reuse)和基于可复用软件(构件)的应用系统构造(集成和组装)(Development with Reuse).
解决好这几个方面的问题才能实现真正成功的软件复用.
与以上几个方面的问题相联系,
实现软件复用的关键技术因素主要包括:软件构件技术(Software Component Technology),领域工程(Domain Engineering),软件构架(Software Architecture),软件再工程(Software Reengineering),开放系统(Open System),软件过程(Software Process),CASE技术等.
除了上述的技术因素以外,
软件复用还涉及众多的非技术因素
,如:机构组织如何适应复用的需求;管理方法如何适应复用的需求;开发人员知识的更新;创造性和工程化的关系;开发人员的心理障碍;知识产权问题;保守商业秘密的问题;复用前期投入的经济考虑;标准化问题等等.
实现软件复用的各种技术因素和非技术因素是互相联系的.它们结合在一起,共同影响软件复用的实现.
2 软件复用的核心技术–软件构件技术
原则
软件开发是一门综合性学科,它包括哲学,基础科学,技术科学,工程管理四个知识层次
.哲学决定着整个学科建立的指导思想,认识论和世界观.认识论就是人们认识客观世界的规律和方法,我们称它为认知体系.
应用软件开发时,有自己必须遵循的哲理和认知观,对基础理论,研究方向以及采用的技术措施起着指导作用,符合学科就能发展,否则就会遇到各种问题,甚至导致失败.从软件发展的几个里程碑中可看出,认知观起到了决定性的作用.
软件开发的初期阶段,我们称为程序设计时代,软件开发处于小作坊个体生产方式水平.到了60年代中期,出现了一些大型复杂的软件系统,人们认识到以个人的能力难以完成一个大系统的任务.W.E.Dijkstra 首先提出了一种解决方案,采用结构程序设计方法,就是把软件开发看作数学求解,沿用数学上的枚举,抽象,归纳,类比等思维方式,把问题简化.用工程的概念,方法,原理和技术来开发和维护软件,产生了结构化分析和设计的方法.这种开发方法长期左右着我国的软件开发,无疑起到了重要作用,然而它仍然存在着认知上的缺陷,如开发周期长,成本高,质量差,特别是所开发的软件不能适应系统的不断演化.
到70年代,人们认识到,仅从软件结构上脉络清晰是远远不够的,这只是”表”,不是”里”,软件在结构上还应该适应客观世界的自然结构.M.A.Jackson认为应用软件应该忠于现实,高于现实,提出JSD系统开发方法,其指导思想是”仿真客观世界”,采用自底后上的设计步骤.JSD方法第一次揭示了客观世界与软件系统之间的关系,因而所开发的软件悟性好,实用性强.然而JSD方法也存在着固有的缺陷:如何仿真要确定系统的实体和活动,它没有给出准则可循;没有区分客观世界的模型和软件系统模型,不能直接映射过去,其结果是系统结构混乱,效率低,软件成份复用性差.
到了80年代,面向对象重新崛起,面向对象的认识论是将系统看成由多个对象组成,通过对象之间的通信形成了系统,为客观世界过渡到软件系统提供了途径和编程的思维方法.
其主要特征是:(1) 类和封装性,实现数据抽象和信息隐蔽,给出了对象类型和参数化,通过生成实例后组装成系统,提供了实现复用的手段.(2) 继承性,提高了代码复用性.(3) 多态性.
面向对象给出了软件系统的体系结构,引入了软件复用的思维方法.近年来引起了越来越多的人关注,提出了多种对象模型,语言,设计了各种基类型库,使得面向对象程序设计逐步成为热点.
问题
面向对象技术虽然被大家接受,公认为当前的发展主流,然而在实际应用时,还存在着一系列问题.
(1) 模型和概念尚未统一,不同的人对系统和对象的理解不一致,导致了各种对象语言均有很大差异,且语言自身与纯面向对象理论有许多不一致的地方,就难以形成统一的标准和开发规范.
(2) 要求使用面向对象技术的人员素质较高,要掌握的东西很多,如要熟练掌握C++必需了解大量的MFC类库,且要了解每个类的细节.
(3) 面向对象复用仅仅是处于初级阶段,未提出任何模式和规范以及相应的管理机制.
(4) 工程上难以实施.目前面向对象能很好应用的领域有限(如VB的界面设计,多媒体软件设计),真正用纯面向对象技术来开发大型软件的并不多,其原因有:如何提炼对象类,采用OOA是不可行的;实际应用领域中的可复用领域专用构件缺乏;由于对象无统一标准,因此还停留在程序员自己复用,很难共享,更谈不上分布式情况下复用;纯面向对象要摒弃原有的许多技术等.产生上述问题的根本原因是由于认知体系上的不完整.由此基于面向对象的构件软件应运而生.
概念
构件(component)简单地说是可复用的软件组成成份,可被用来构造其他软件.构件(Component)是指应用系统中可以明确辨识的构成成分.而可复用构件(Reusable Component)是指具有相对独立的功能和可复用价值的构件
.它可以是被封装的对象类,类树,一些功能模块,软件
框架
(framwork),软件构架(或体系结构Architectural),文档,分析件,设计模式(Pattern)等.构件分为构件类和构件实例,通过给出构件类的参数,生成实例,通过实例的组装和控制来构造相应的应用软件.
可复用构件应具备以下属性 [Tracz 95]:①有用性(Usefulness):构件必须提供有用的功能;②可用性(Usability):构件必须易于理解和使用;③质量(Quality):构件及其变形必须能正确工作;④适应性(Adaptability):构件应该易于通过参数化等方式在不同语境中进行配置;⑤可移植性(Portability):构件应能在不同的硬件运行平台和软件环境中工作.
随着对软件复用理解的深入,
构件的概念已不再局限于源代码构件,而是延伸到需求,系统和软件的需求规约,系统和软件的构架,文档,测试计划,测试案例和数据以及其他对开发活动有用的信息.这些信息都可以称为可复用软件构件.
软件系统的复杂性不断增长,软件从业人员的频繁流动和同行之间的激烈竞争迫使软件企业提高软件质量,积累和固化知识财富,并尽可能缩短软件产品交付时间.集软件复用,分布式对象计算,CASE和企业级应用程序开发(EAD)等技术为一体,”
基于构件的软件开发
“(Component-Based Software Development,简称CBSD或CBD)以软件构架为组装蓝图,以可复用软件构件为组装预制块,支持组装式软件复用,是提高软件生产效率和产品质量,减轻人员流动副作用,缩短产品交付时间的现实有效的途径之一.
CORBA,Microsoft Visual Studio,UML,UNIFACE,Oracle8,三层结构,JavaBean,ActiveX,…,几乎所有的软件开发新技术和新产品都高唱CBD的主题,以自己的理解为下一代软件开发提供技术支持.尽管CBD涉及软件开发的方方面面,但是其核心技术和难点都集中在构件构架技术上.经过几年的发展,构件本身的模型及其规范已经提出,较有影响是OLE的COM及CORBA的SOM.目前已发展到分件式构件规范,主要有CORBA,OLE/ActiveX和JaveBeans,其发展日趋明朗,最终将会趋向统一.
为了更好地了解构件的性质,我们把它按多个侧面进行分类:(1) 按开发过程构件分为分析件,设计件,程序件和数据件.(2) 按功能分,分为三层:基础层为基本数据类构件和系统支撑构件;中间层为各种通用的中间件,顶层为针对领域的专用构件或子系统构件,从粒度上看,通常底层的粒度为较小,而顶层的粒度为较大.(3) 按使用方式分为动态和静态两种.(4) 按构件的结构分为原子构件及由多个构聚集的组合构件.
技术
软件构件技术是支持软件复用的核心技术
,是近几年来迅速发展并受到高度重视的一个学科分支.其主要研究内容包括:
构件获取:有目的的构件生产和从已有系统中挖掘提取构件;
构件模型:研究构件的本质特征及构件间的关系;
构件描述语言:以构件模型为基础,解决构件的精确描述,理解及组装问题;
构件分类与检索:研究构件分类策略,组织模式及检索策略,建立构件库系统,支持构件的有效管理;
构件复合组装:在构件模型的基础上研究构件组装机制,包括源代码级的组装和基于构件对象互操作性的运行级组装;
标准化:构件模型的标准化和构件库系统的标准化.
应用
根据IDG和Gartner等组织的预测,今后,软件开发商必须了解主要系统集成商和应用软件开发人员所需要的基本构件,因为他们在引导着构件技术的需求和功能走势.到2001年,所有新开发的应用至少有60%将是基于构件的组装,开发商的市场应变能力也因此得到提高.围绕构件的生产,管理和组装将形成具有相当规模的构件市场和CBD工具市场.随着应用的推广和深入,对构件组装技术,软件构架技术,分析设计构件的描述和复用,特定领域软件构架,构件库部署等问题的研究也会不断发展.
以面向对象为基础而发展起来的软件构件技术,摆脱了面向对象的理论束缚,目前理论上还未完善,但实际应用却有较大进展.在国内,构件软件的理论和实际工程已被人们普遍关注.在理论上,北京大学,中科院软件所,吉林大学,南京大学,复旦大学,中山大学等单位,均发表了不少有价值的学术论文.在实际工程上,青鸟公司,中软公司,华科电脑公司,特宝科公司,天中公司等均采用
基于构件技术
开发应用软件,积累了不少经验,获取极好的效益.预计在不久的将来,构件软件技术将会在全国普遍开花.构件软件技术还处于发展阶段,目前迫切需要解决以下问题:针对如何开发应用,需要有一套开发规范和质量保证体系;如何提取领域构件,仍然是处于摸索阶段.开始时,我们是采用通过功能划分来提取构件,这就影响构件的可复用性,目前可以采用领域中的模型和各种设计模式来提取构件是一条好的途径,但还未总结出可操作的规程;最后鉴于分布式系统网络系统和多媒体应用,国际上的复合文档和Java正处于迅速发展时期,在我国还缺乏实际应用的经验.
以下,将对构件模型与构件描述语言,构件的获取,构件的表示和检索,构件组装,软件构架技术和构件库的标准化等方面进行简要的介绍.
2.1 构件模型和构件描述语言
研究构件软件的两个核心是:如何提取可复用构件以及如何组装成系统并能实现互操作.
目前讨论的软件体系结构,构件模型,均是为解决构件之间的接口,实现互操作.近年国际已提供了各种构件库,如MFC,PBL,VBL等等.但是这类类库绝大多数属于基本数据类库,制作界面的控件,各种中间件,支撑件及系统件等类库.但是离要集成应用软件所需要的构件还有很大距离.虽然国际上各种软件公司正在开发各种中间件产品或领域构件,但常常是不能拿来就用,如开发MIS系统时的Form操作构件,查询统计构件以及报表生存构件,特别是一些与领域有关的专用构件,必须要自己开发.那
么如何提取领域构件,国际上还没有一种可循的办法,也就是说我们在开发应用软件的同时,难以形成相应的领域构件,以便适应系统自身演化或可复用到同领域中的不同系统的开发中.
实现CBD必须首先回答”
构件是什么
“的问题,建立或采纳标准化的构件模型.构件模型定义了构件的本质属性,规定了构件接口的结构以及构件与软件构架,构件与构件之间的交互机制.构件模型通常还提供创建和实现构件的指导原则.CBD工具可以识别和组装来自不同开发者的符合同一构件模型的构件.一个被所有构件生产者和构件复用者所接受的构件模型实际上起到了构件标准化的作用.
在学术界和产业界已经出现了多种构件模型,其中”3C”模型是学术界普遍认同的一个具有指导性的构件模型.该模型从概念(concept),内容(content)和语境(context)三个不同方面来描述构件:
概念 – 关于”构件做什么”的抽象描述,可以通过概念去理解构件的功能.概念包括接口规约和语义描述两个部分;
内容 – 概念的具体实现,描述构件如何完成概念所刻划的功能;
语境 – 构件和外围环境在概念级和内容级的关系.语境刻划构件的应用环境,为构件的选用和适应性修改提供指导.
而DCOM/COM+,JavaBean/Enterprise JavaBean和CORBA构件模型三足鼎立,构成了实现级构件模型工业标准的竞争与互操作并存的格局.现有的构件模型一般认为构件由构件接口(对应于3C模型中的概念和概念级语境)和构件内容两部分组成.构件接口就是为成功复用该软件实体而需要提供给外界的所有信息,包括构件向外提供的和请求的服务,构件的自述信息和定制信息,构件的初始化,实例化和永久化方法以及构件对目标复用环境的依赖和构件组装信息等;构件内容就是用于直接复用的软件实体,它可以具有源代码,二进制码,文档,分析设计模型和脚本等不同的物理形态,并遵从一定的格式标准.
构件是为了复用,就必需遵循一定的规范,通过语言的功能来实现规范是一种极好手段.按照应用软件开发过程,可以提供下述语言.
(1) 构件描述语言,用来描述构件的规格说明,即描述设计件;也可用来检索已有的可复用构件,是设计构件检索语言的依据.
(2) 构件编程语言.可以采用现在流行的各种编译程序,如VC,VB,Java等.
(3) 过程控制语言和系统集成.通过过程控制来制作专用构件,子系统构件和应用软件,要提供连接和嵌入的功能,还要包括面界开发功能,构件库的管理和实例生成,要提供数据库设计和数据库连接的功能,还提供大量的基本构件,中间构件及APL.如PB,Delphi等.由于PB易于掌握,除提供上述功能外,又能用于编程和构件管理,它通过不断版本更新,能紧跟新技术的发展,因此普遍受到软件开发者的青睐.
建立在构件模型的基础上,构件描述语言(Component Description Language)以一种严格而又易于理解的方式,为协作构件,构件组装工具和CBD开发人员提供全面准确的构件信息.构件描述语言是从70年代的模块互联语言MIL,80年代的构件描述语言CDL和90年代的构架描述语言ADL发展而来的.CDL的基本思想是将构件视为黑盒,通过描述构件接口的语法和语义向外界提供构件的结构和行为信息,使构件复用者不必关心其内部细节.CORBA IDL,DCOM ODL和IDL等接口描述(或定义)语言都能够描述构件接口的语法,并且具备编译和浏览工具的支持;但是现有的接口描述语言在描述构件接口语义和构件间复杂的交互协议方面缺乏进一步的支持.
针对基于构件的应用软件开发过程,中科院软件所仲萃豪等人提出了三个阶段的生命周期,即软件开发模型.
数据库设计时分为概念设计,逻辑设计和物理设计三个阶段,应用软件开发过程也分三个阶段.
第一阶段为需求获取,采用仿真办法,描述客观世界的人工系统.在八?五时期,他们试验成功了”角色法”的描述方法,设计出领域需求报告可复用构件,用HIPO图,半形式方式描述出客观系统.
第二阶段是分析客观系统,设计出逻辑系统,称为领域分析.由于客观系统和软件系统在概念,结构,功能,通信方式均有很大差异,虽然都是采用面向对象的概念来形成,但客观世界的对象是实体,没有类的概念;客观世界是一种功能模型,而软件系统是面向封装后的对象组成.要把从客观系统转换到软件系统,且要有利于实现复用,为此他们提出了一种过渡用的软件系统,把与领域有关的不变部分和可变部分分开,设计出领域软件的
框架
,提取出领域软件,设计出主题数据库,由此形成了与领域有关的逻辑系统,以上各部分结果,我们统称为设计件.
在开出构件的规格说明后,就可以编制构件类,构件类树,为实现领域的群体开发作好一切文档准备.
第三阶段为系统集成,找到合适构件类,将其生成实例,用过程控制语言描述出系统中的各子系统;配置用户喜爱的操作界面;生成各种输入输出构件实例等.最后集成系统,通过实际运行,不断修改,直到用户完全满意为止,这种方法也能适应今后系统的演化.一旦领域软件系统形成后,在开发同一领域的应用软件时仅仅是第三阶段的工作,用户自己可以来完成,维护工作也大大减轻.
上述开发过程中,软件开发人员可以分工去做.先由咨询公司或软件公司完成第一,第二阶段工作,由软件产品开发公司完成逻辑系统,提供领域分析的设计件,领域专用或通用的构件类库以及系统集成专用平台,再由集成公司或用户自己来完成第三阶段工作.
2.2 构件的获取
构件模型和软件构架为基于构件的软件开发奠定了基础,但是在实际应用CBD技术时还必须具备大量可供选择的可复用构件.构件的获取手段有多种,既可以商业采购得到COTS(Commercially-Off-The-Shelf)构件(如开发环境中自带的ActiveX控件和Delphi构件),也可以利用项目承包商和合作伙伴开发的NDI构件(Non-Developmental Item),或者在领域工程和再工程的基础上从已有应用系统中发掘和提炼可复用构件,或者针对新需求和新技术从头自主开发新构件.不论以何种方式获得的构件,都必须经过严格的测试和认证,在构件库中统一管理.对于外来构件,除了要考察其质量和可用性,还必须考虑日后构件维护和版本升级的成本.
伴随一种构件模型的提出,应该同时提供构件开发和封装工具,或者一整套构件开发和构件组装的指导原则,为构件开发者提供工具辅助和技术支持.构件开发者则利用特定领域的开发经验制作能够满足领域普遍需求的可复用构件.目前市场上已经有大量面向GUI,数据库和网络的VBX与ActiveX控件,JavaBean和Delphi构件,以及众多的类库,DLL接口和API,这些源代码和目标码构件大大提高了程序员的工作效率.但遗憾的是,具有更高复用价值的分析设计构件以及面向特定应用领域(而不是计算机领域)的业务构件还非常少见.
2.3 构件的表示和检索
构件的表示和检索机制的研究一直是构件库研究的热点:一方面,拥有大量可复用构件的组织必须以一种易于分类管理而又方便复用者检索的机制来表示和保存构件资产;另一方面,有效的构件检索机制能够降低构件查找和理解的成本,而构件的合理表示和分类正是实现高效方便的检索的基础.
目前有很多构件分类和检索方法,从构件表示出发可以分为人工智能方法,超文本方法和信息科学方法三类;而根据复杂度和检索效果的不同则可以分为基于文本的,基于词法描述子的和基于规约的编码和检索.信息科学方法是实际复用项目中应用较为成功的一类,并且以枚举,刻面,属性值,关键词和正文检索几种方法较为常见,其中刻面分类方法能够表达丰富的构件信息,尤其为人关注.刻面分类(Faceted Classification)方法将关键词(术语)置于一定的语境中,并从反映构件本质特性的不同视角(刻面)将构件分类.每个刻面中有一组术语(关键词),术语间由于有一般特殊关系和同义词关系而形成结构化的术语空间.构件的描述术语仅限在给定的刻面之中选取.在术语空间中游历可以帮助复用者理解相关领域.术语空间可以演变.
2.4 构件组装
基于构件的开发通过构件组装得到最终应用系统,构件组装必须以某个
框架
或构架为蓝图,实际可以看作是用构件实例将软件构架具体化的过程.构件组装技术以构件模型,构件-构架描述和开放系统技术为基础,成功的组装必须以开放构件模型和规范的构架描述(包括对构件连接和交互协议的严格定义)为基础,构件实例必须符合系统中其他部分的要求.分布式软件总线,事件登记和回调,构架描述语言,脚本语言和代码生成技术都为构架组装指出了希望之路,DCOM,JavaBean等运行级的分布式构件模型的出现和ORB与Internet的引入,使构件之间的独立性和互操作性变得更强,这些技术为构件组装,尤其是运行级的构件组装提供了有力的支持.
基于控件的GUI构造和4GL工具可以被组装工具的成功范例,但目前仍然缺乏通用的构件组装方法.一个可用的构件组装工具应该具有构件的浏览和定制,构件的图形化表示和操纵,以及目标系统(半)自动生成等功能.真正意义上的CBD应该在分析,设计,实现和系统部署等不同阶段,在函数,对象,模块,
框架
,服务进程和程序等不同粒度上,从构件构架的开发,描述,浏览,插装,定制等不同方面对构件组装提供全面的支持.
2.5 构件及构件库的标准化
美国军方与政府资助的项目中,已建立了若干构件库系统,如CARDS,ASSET,DSRS等.由DARPA发起,由美国军方,SEI和MITRE支持的STARS项目在此基础上考虑了开放体系结构的构件库之间共享资源和无缝互操作的问题,并于1992年提交了ALOAF(Asset Library Open Architecture Framework,开放体系结构的构件库
框架
)Version1.2版本.这一报告体现了STARS对可复用构件库系统的认识,给出了一个构件库
框架
的参考模型,并就此实现了ALOAF规约作为该参考模型的实例,由此证明以公共
元模型
为基础,在构件库之间交换信息和创建易于移植的复用工具是可能的和必要的.
ALOAF的短期目标是尽快实现不同复用库间的构件共享,长期目标是实现异质构件库间的无缝互操作,包括构件及其描述的共享及丰富的构件库工具集的易移植性.其基本观点是软件系统的开发将演化成一种过程驱动的,特定于领域的和基于复用的技术支持范型.STARS认为构件库是软件工程环境(SEE)的子系统之一,其提供的功能应与SEE
框架
的参考模型一致.构件库系统利用SEE提供的服务,并向上层提供服务.ALOAF更关注构件库
框架
而非更广泛的SEE
框架
.ALOAF包括构件库参考模型及其服务规约和数据描述规约.ALOAF在构件库和复用服务方面对SEE参考模型进行补充.
可复用库互操作组织(Reuse library Interoperability Group,缩写为RIG)是一个志愿的基于一致意见的组织,由来自政府,学校和私人企业的成员组成.RIG认为,当前几乎没有有效的方法在众多的政府和企业界软件复用库间共享软件构件,其结果是低效和不必要的冗余.可互操作性,即复用库间软件构件的共享,可能是在短期内提高效率,增加复用库的价值和影响,并在长期中避免不兼容协议的爆炸性增长的关键.因此,RIG的目标是致力于开发可互操作性的解决方案.RIG的成果包括BIDM和UDM [RIG 93] [RIG 94].UDM是基于ALOAF的三层数据模型的统一数据模型.BIDM是UDM的一个子集,定义了为了实现互操作,复用库交换软件构件时所需的信息的最小集.BIDM已被IEEE采纳为标准.
北大西洋公约组织(NATO)针对NATO,NATO参与国和承包商制定了一组关于软件复用的标准,其中包括”可复用构件开发标准”,”可复用软件构件库管理标准”,”软件复用过程标准” [NATO 91a] [NATO 91b] [NATO91c]. 制订这些标准的目标是供NATO及其参与国的项目管理部门使用它们来建立复用计划需求和向承包商提供指导.承包商则将它们用于特定项目的开发实践.
2.6 构件组装技术
CORBA是公共对象请求代理体系结构(Common Object Request Broker Architecture)的缩写,是对象管理组织(OMG)开发的一套分布式对象技术标准,涉及接口,注册,数据库,通信和出错处理等方面的问题 [OMG 96].和对象管理体系结构(OMA)定义的其他对象服务相结合,CORBA成为支持分布式系统中对象技术的中间件设施.CORBA的对象请求代理(ORB)作为转发消息的中间件,实现了对象间的无缝集成和互操作.因此,CORBA可作为面向对象的软件构件在运行级上组装的技术基础,从而实现构件的黑盒复用.当前已有许多符合CORBA的ORB产品,如ORBIX,NEO,VisiBroker,PowerBroker,SmallTalkBroker,SOM/DSOM,DAIS,NonStop等.
OLE是微软公司开发的支持对象连接嵌入的机制,其初旨是解决复合文档问题 [Microsoft 95].OLE为构件对象的互操作提供了基础支持,因此,也为构件的黑盒复用提供了技术基础.OLE是主要的不符合CORBA标准的对象连接中间件.DCOM是微软公司开发的分布式构件对象模型,支持分布式系统中的面向对象技术 [Microsoft 96].
JAVA是近几年随着WEB风行全球而发展起来的一种新语言.它是一种纯OO的语言,外观象C++,内核类似Smalltalk.JAVA和WEB的结合带来了移动的对象,可执行的内容等关键概念.JAVA具有体系结构中立的特性,从而使得JAVA程序可不需修改甚至重编译而运行于不同平台之上.JAVA的新版还加入了远程方法调用(RMI)的特性,在效果上,RMI提供了类似CORBA的ORB的功能.JAVA的这些特性使其成为软件构件技术的良好支持工具.用JAVA书写的构件将具有平台独立性和良好的互操作性.
这些技术的流行为构件组装提供了很好的技术支持,同时它们也为构件提供了实现标准.软件复用和分布对象技术的结合使得即插即用的构件黑盒组装成为可能.
3 复用的其它相关技术
3.1 领域工程
从软件开发过程的角度看,有关软件复用的问题可以分为两类,一类是关于面向复用的开发(Development for Reuse),另一类是关于基于复用的开发(Development with Reuse).
第一类问题主要是关于如何产生具有较高可复用性的构件或生成过程,第二类问题包含三个方面,即:如何找到可复用构件,如何判断可复用构件是否符合当前需要,以及如何对可复用构件进行适应性修改 [Mili 95].领域工程有助于这些问题的解决,从而对软件复用提供了有力的支持.
领域工程有助于产生具有较高可复用性的构件.领域工程将关于领域的知识转化为领域中系统共同的规约,设计和构架,使得可以被复用的信息的范围,扩大到了抽象级别较高的分析和设计阶段.由于通过领域工程产生的可复用构件来源于领域中现有的系统,体现了领域中系统的本质需求,因此这些构件具有较高的可复用性 [Prieto 87].
同时,领域工程产生了领域模型和特定领域的软件构架(DSSA)或应用系统的生成过程,这对于基于复用的开发很有帮助.可复用构件是根据领域模型和DSSA组织的,方便了构件的检索.开发以领域模型和DSSA为线索进行,可以帮助开发者识别复用机会,判断可复用构件是否符合当前需要.DSSA为构件组装提供了上下文,使得利用可复用构件组装或生成新的系统较为容易.
领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程,它覆盖了建立可复用的软件构件的所有活动[Tracz 95].其中”领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域.
领域工程对领域中系统的进行分析,识别这些应用的共同特征和可变特征,对刻划这些特征的对象和操作进行选择和抽象,形成领域模型,依据领域模型产生出领域中应用共同具有的体系结构(即特定领域的软件构架,缩写为DSSA)或生成过程,并以此为基础识别,开发和组织可复用构件 [Prieto 90].这样,当开发同一领域中的新应用时,可以根据领域模型,确定新应用的需求规约,根据特定领域的软件构架形成新应用的设计,并以此为基础选择可复用构件进行组装,从而形成新系统.
领域工程包括三个主要的阶段:
领域分析:这个阶段的主要目标是获得领域模型(Domain Model).领域模型描述领域中系统之间的共同的需求 [Petro 95].这个阶段的主要活动包括确定领域边界,识别信息源,分析领域中系统的需求,确定哪些需求是被领域中的系统广泛共享的,哪些是可变的,从而建立领域模型.
领域设计:这个阶段的目标是获得领域构架(Domain-Specific Software Architecture,缩写为DSSA).DSSA描述在领域模型中表示的需求的解决方案,它不是单个系统的表示,而是能够适应领域中多个系统的需求的一个高层次的设计 [Petro 95].建立了领域模型之后,就可以派生出满足这些被建模的领域需求的DSSA.由于领域模型中的领域需求具有一定的变化性,DSSA也要相应地具有变化性.
领域实现:这个阶段的主要行为是定义将需求翻译到由可复用构件创建的系统的机制.根据所采用的复用策略和领域的成熟和稳定程度,这种机制可能是一组与领域模型和DSSA相联系的可复用构件,也可能是应用系统的生成器.
这些活动的产品(可复用的软件构件)包括:领域模型,领域构架,领域特定的语言,代码生成器和代码构件等.
在领域工程的实施过程中,可能涉及的人员包括 [Cohen 92]:
最终用户:使用某领域中具体系统的人员;
领域专家:提供关于领域中系统信息的人员,他应该熟悉该领域中系统的软件设计和实现,硬件限制,未来的用户需求及技术走向;
领域分析员:收集领域信息,完成领域分析并提炼出领域产品(可复用软件构件)的人员,他应该具有完备的关于复用的知识,并对分析的领域有一定程度的了解;
领域分析产品(构件,构架)的使用者:包括最终用户,应用系统的需求分析员和软件设计者.
研究实践表明,软件复用在特定领域内更容易获得成功.因此,领域工程受到高度重视,已有许多研究成果.
三个有代表性的工作是:
卡内基.梅隆大学的软件工程研究所(CMU/SEI)提出的面向特征的领域分析方法(Feature-Oriented Domain Analysis Method,缩写为FODA方法) [Foreman 97].它支持对某领域中系统共性和个性的发现,分析和文档记录.FODA的过程分为三个阶段:上下文分析(Context Analysis),领域建模(Domain Modeling),构架建模(Architecture Modeling).FODA方法已成功地应用于美国空军运动控制等领域.
在美国国防部高级研究项目署(ARPA)资助下,建立了”用于易修改的可靠系统的软件技术”项目,研究领域特定的,基于复用的软件工程技术,并建立了三个示范工程项目.美国空军电子系统中心与美国航空航天局合作建立了”可复用防务软件的中央档案库”项目,以促进国防项目中的软件复用.Will Tracz提出了领域构架方法(Domain-Specific Software Architecture,缩写为DSSA方法) [Tracz 95].在最高的级别上,该方法有五个阶段.每个阶段可以进一步划分为一些步骤或子阶段.每个阶段包括一组需要回答的问题,一组需要的输入,一组将产生的输出和验证标准.该方法的领域工程过程是并发的(concurrent),递归的(recursive)和反复的(iterative).或者可以说,它是螺旋型的(spiral).完成该过程可能需要对每个阶段经历几遍,每次增加更多的细节.
STARS领域分析过程(Domain Analysis Process)分准备领域信息,分类领域实体,导出领域模型,扩展模型并分类四个阶段,每个阶段用结构化分析与设计技术描述,使用SADT图 [Tracz 95].
3.2 软件构架
软件构架(又称软件体系结构)是对系统整体结构设计的刻划,包括全局组织与控制结构,构件间通讯,同步和数据访问的协议,设计元素间的功能分配,物理分布,设计元素集成,伸缩性和性能,设计选择等 [Garlan 93].
软件构架为CBD提供了构件组装的基础和上下文.
一个典型的软件构架是由系统中的构件,连接子和约束构成的配置格局.研究软件构架有利于发现不同系统的高层共性,保证灵活和正确的系统设计,对系统的整体结构和全局属性进行规约,分析,验证和管理.将构架作为系统构造和演化的基础,可以实现大规模,系统化的软件复用.
研究软件构架对于进行高效的软件工程具有非常重要的意义:通过对软件构架的研究,有利于发现不同系统在较高级别上的共同特性;获得正确的构架对于进行正确的系统设计非常关键;对各种软件构架的深入了解,使得软件工程师可以根据一些原则在不同的软件构架之间作出选择;从构架的层次上表示系统,有利于系统较高级别性质的描述和分析.特别重要的是,在基于复用的软件开发中,为复用而开发的软件构架可以作为一种大粒度的,抽象级别较高的软件构件进行复用,而且软件构架还为构件的组装提供了基础和上下文,对于成功的复用具有非常重要的意义.
软件构架研究如何快速,可靠地从可复用构件构造系统的方式,着重于软件系统自身的整体结构和构件间的互联.其中主要包括:软件构架原理和风格,软件构架的描述和规约,特定领域软件构架,构件向软件构架的集成机制等.
软件开发实际上是从问题域向最终解决方案逐步映射和转换的过程,而特定领域软件构架(DSSA)和软件构架风格(Architectural Style)分别从问题域和软件解决方案两个方向提供了若干经过考验的候选转换路径
.特定领域软件构架是一个领域中的所有应用系统所共有的体系结构,是针对领域模型中的领域需求给出的解决方案,也是识别,开发和组织特定领域可复用构件的基础.在国内外的金融,MIS,CIMS和军事等领域中都开始注意开发特定领域的软件构架和集成
框架
的重要性.体系结构风格则根据系统结构的组织模式确定了一组可以用于风格实例中的构件和连接子,以及它们的拓扑结构,组装规则以及局部和全局约束,从而定义了一个面向系统结构的构架家族.软件构架风格与面向对象的设计模式或
框架
一样,为设计经验的复用提供了技术支持.Client/Server,分层的体系结构(Layered),分布式对象计算(Distributed Object Computing),管道和过滤器(Pipe & Filter),黑板系统(Blackboard)等都是广泛使用的软件构架风格.
3.3 软件再工程
软件复用中的一些问题是与现有系统密切相关的,如:现有软件系统如何适应当前技术的发展及需求的变化,采用更易于理解的,适应变化的,可复用的系统软件构架并提炼出可复用的软件构件 现存大量的遗产软件系统(Legacy Software)由于技术的发展,正逐渐退出使用,如何对这些系统进行挖掘,整理,得到有用的软件构件 已有的软件构件随着时间的流逝会逐渐变得不可使用,如何对它们进行维护,以延长其生命期,充分利用这些可复用构件 等等.软件再工程(Software Reengineering)正是解决这些问题的主要技术手段.
软件再工程是一个工程过程,它将逆向工程,重构和正向工程组合起来,将现存系统重新构造为新的形式 [Feiler 93].再工程的基础是系统理解,包括对运行系统,源代码,设计,分析,文档等的全面理解.但在很多情况下,由于各类文档的丢失,只能对源代码进行理解,即程序理解.
一个再工程的
框架
给出了进行一次再工程实践的全过程中所应当考虑的活动,它对人们如何对遗产系统进行再工程开发具有指导性意义.当然,一个这样的
框架
所给出的并不是一个需要严格遵守的活动规范,它所起的作用只是提醒人们在进行再工程的过程中需要注意哪些问题,而且针对不同的具体系统,可能会需要进行相应的修改才能适应具体问题的需求.
一个再工程的过程主要由决策分析,系统理解,和系统演化三个部分组成.
决策分析的活动包括:确定再工程活动的范围和方向;建立反映未来系统的质量提高的初始系统需求;对遗产系统的详细审查和分析等.决策的目的是在再工程,维护和新开发之间进行选择,决定是否要进行再工程.
如果决策分析决定进行再工程,就要开始对遗产系统进行系统理解.系统理解的功能是通过对遗产系统的源代码,设计记录以及其它文档资源的分析,得到对系统的全面而详细的信息,为从遗产系统到未来系统的转化提供坚实的基础.
对系统全面理解之后,就可以进行系统演化.系统演化通过对遗产系统的改造和重组,将之转化为未来系统.对于一个大的遗产系统,针对其不同部分和所期望的系统之间的距离,所使用的演化策略是不同的,主要可以有维护,改造和替换三种方法.
3.4 开放系统技术
开放系统技术的基本原则是在系统的开发中使用接口标准,同时使用符合接口标准的实现.这些为系统开发中的设计决策,特别是对于系统的演化,提供了一个稳定的基础,同时,也为系统(子系统)间的互操作提供了保证.开发系统技术具有在保持(甚至是提高)系统效率的前提下降低开发成本,缩短开发周期的可能.对于稳定的接口标准的依赖,使得开发系统更容易适应技术的进步 [Foreman 97].当前,以解决异构环境中的互操作为目标的分布对象技术是开放系统技术中新的主流技术.
开放系统技术为软件复用提供了良好的支持.特别是分布对象技术使得符合接口标准的构件可以方便地以”即插即用”的方式组装到系统中,实现黑盒复用.这样,在符合接口标准的前提下,构件就可以独立地进行开发,从而形成独立的构件制造业.
3.5 CASE技术
随着软件工程思想的日益深入人心,以计算机辅助开发软件为目标的CASE(Computer Aided Software Engineering)技术越来越为众多的软件开发人员所接受,CASE工具和CASE环境得到越来越广泛的应用.CASE技术对软件工程的很多方面,例如分析,设计,代码生成,测试,版本控制和配置管理,再工程,软件过程,项目管理等等,都可以提供有力的自动或半自动支持.CASE技术的应用,可以帮助软件开发人员控制软件开发中的复杂性,有利于提高软件开发的效率和质量.
软件复用同样需要CASE技术的支持.CASE技术中与软件复用相关的主要研究内容包括:在面向复用的软件开发中,可复用构件的抽取,描述,分类和存储;在基于复用的软件开发中,可复用构件的检索,提取和组装;可复用构件的度量等等.
4 基于复用的软件开发过程
软件过程又称软件生存周期过程,是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合.一个良好定义的软件过程对软件开发的质量和效率有着重要影响.当前,软件过程研究以及企业的软件过程改善已成为软件工程界的热点,并已出现了一些实用的过程模型标准,如CMM,ISO9001/TickIT等.
然而,基于构件复用的软件开发过程和传统的一切从头开始的软件开发过程有着实质性的不同,探讨适应于软件复用的软件过程自然就成为一个迫切的问题.
Caldieri和Basili提出了一种工厂化的软件生产方式 [Caldiera 91].在这种模型中,构件生产组和系统开发组间严格按照生产者?消费者关系进行任务分工,经验工厂负责生产,提供构件,项目组不再编程,而是通过从经验工厂中请求所需的构件集成组装而得到最终所需的系统.经验工厂的活动分为同步活动和异步活动.同步活动指配合项目组的活动,接收构件查找请求或定制请求,为项目组服务.异步活动指有目的的构件生产或对同步活动中的构件进行再工程以提高构件的可复用性.
4.1 产品线系统
产品线系统(Product Line System)是CMU/SEI提出的产品开发的组织方式.产品线集中体现了软件复用思想.经验表明,单靠技术方法并不能保证成功的产品线生产能力,经济,组织,管理和过程在建立和维护产品线中起到了关键作用.一个产品线是共享一组共同设计及标准的产品族,从市场角度看是在某市场片断中的一组相似的产品.建立产品线是根据生产的经济学,使产品族可复用构件能达到最大限度的复用目的.产品线方法可以通过各种可复用软件构件,如需求,需求规约,构架,代码构件,文档,测试策略和计划,测试案例和数据,开发人员的知识和技能,过程,方法及工具等,支持最大限度的软件复用.产品线也是基于在相同产品价格条件下提高竞争力的商业考虑.
产品线系统已有成功的应用实例.典型的是美国空军电子系统中心(ESC)和瑞典CelsiusTech System公司的产品线系统.
在ESC采用的产品线方法[Brownsword 96]中,主要有五个关键性的组织,即外围的用户,SPO(系统项目办公室),和产品线内部的系统构架组,产品线工程中心和产品线构件支持组.SPO是直接和用户打交道的组织,由它来决定是开发一个新系统还是从已有的系统升级.SPO和用户都是产品的客户,它们介入了整个开发阶段,在系统从原型演化到最终部署的过程中进行监控和认证.产品线内部的三个关键性组织分别是系统构架组(SAG),产品线工程中心(PLEC),产品线构件支持组(PLAS).
CelsiusTech系统公司是瑞典主要的命令与控制系统供应商.1985年12月,该公司同时接到了两份合同-瑞典海军和丹麦海军的轮船系统,两个系统都需要很强的容错性和分散性,比以往开发的系统要复杂得多.在面临两个结构类似的大型系统的并行开发情况下,以前开发单个系统的方法需要大量的投资和人力,因此公司的管理者和高级技术人员决定采用一种新的产品族系列的开发方法,这就是SS2000产品线 [Cohen 96].采用SS2000产品线方法后,CelsiusTech公司获得了巨大的成功,将硬件与软件的费用比例从过去的35:65变成了80:20.由于软件的费用得到了良好的控制,该公司现已把精力投入到了降低硬件费用上.
这两个产品线系统的共同特点是构架组,构件组和集成组的分离.构架组负责产品线系统构架的定义和演化.构件组负责根据产品线系统构架,生产和管理可复用构件.集成组则根据具体客户的需求,利用产品线系统构架和可复用构件进行具体的系统集成.
使用产品线方法的好处是显而易见的,它将以更小的代价和资源,更快地开发出系统.由于使用的是高度可靠,性能经过验证的可复用构件,产品线系统的质量将大大提高.而且产品线方法还开拓了一个广阔的构件市场,这将极大地促进软件构件业的发展.
但是,产品线方法仍然面临着很大的挑战和障碍,这主要体现在:
文化上-产品线策略意味着软件组织和管理者对他们产品开发的直接控制减少了,对其它组织的依赖增加了,这意味着一种思想观念上的转变.
战略计划上-产品线的规划不仅是对一组相关系统的管理过程,还需要考虑用户的长期需要和现有产品线的能力,对未来的发展作出长远规划.
需要折衷-产品线方法需要用户作出折衷,是”独自开发一个恰好是我所需要的系统”,还是”利用产品线开发一个与我的需要非常接近的系统,但可以节省开发的代价和时间”.
资源的所有权-产品线构件归谁”所有” 在目前的体制下,这的确是一个容易引起纠纷的问题.这就需要整个软件开发和管理组织的重心从当前的程序获取转移到商业化的构件开发上来.
提拔和奖励-当前的开发方法主要是提拔和奖励那些提交了最终系统的开发人员,采用产品线方法后还应该提拔和奖励那些开发构件和促进了产品线开发中构件复用的人员.
4.2 复用成熟度模型(RMM)
受SEI的能力成熟度模型(Capability Maturity Model,缩写为CMM)的启发,已出现了几个复用成熟度模型(Reuse Maturity Model,缩写为RMM),作为对企业内复用水平层次的度量.
在IBM的RMM中,将企业的软件复用水平分为五级.随着复用成熟度级别的提高,复用的范围,复用使用的工具和复用的对象都有变化
:①初始级(Initial):不协调的复用努力.复用是个人的行为,没有库的支持,主要的复用对象是子程序和宏;②监控级(Monitored):管理上知道复用,但不作为重点.复用是小组的行为,有非正式的,无监控的数据库,复用的对象包括模块和包;③协调级(Coordinated):鼓励复用,但没有投资.复用的范围包括整个部门,有配置管理和构件文档的数据库,复用的对象包括子系统,模式和
框架
;④计划级(Planned):存在组织上的复用支持.在项目级别支持复用,有复用库,复用的对象包括应用生成器;⑤固有级(Ingrained):规范化的复用支持.复用成为整个企业范围的行为,有一组领域相关的复用库,复用的对象包括DSSA.
Loral Federal System公司的RMM也分为五级
:①初始级:偶尔的开发过程复用;②基本级:在项目级上定义的开发过程复用;③系统化级:标准的开发过程复用;④面向领域级:大规模的子系统复用;⑤软件制造级:可配置的生成器及DSSA.
HP的RMM将复用成熟度与复用率联系起来,也分为五级
:①无复用:-20%至20%的复用率;②挖掘整理:15%至50%的复用率;③计划复用:30%至40%的复用率;④系统化复用:50%至70%的复用率;⑤面向领域的复用:80%至90%的复用率.
5 结束语
自软件复用被提出以来,人们进行了许多复用的实践活动.归纳起来,复用项目的成功主要发生于以下几种情形
:①在较小的特定领域;②在理解充分的领域;③当领域知识变动缓慢时;④当存在构件互联标准时;⑤当市场规模形成时(大量的项目可以分担费用);⑥当技术规模形成时(有大量可用的,可获利的构件).
而复用项目失败的原因主要包括
:①缺乏对复用的管理支持;②没有对开发可复用软件及复用已有软件的激励措施;③没有强调复用问题的规程或过程;④没有足够的可复用资源;⑤没有良好的分类模式,使得构件查找比较困难;⑥没有良好的构件库支持和控制复用;⑦构件库中的构件没有良好的接口;⑧已有的部件不是为了复用而开发的.
经过软件复用的研究和实践方面的努力,在构件开发方面已经取得一定的成果.当前已存在一些政府,军方或企业自己拥有的构件库,在某些领域,如科学计算,已有商用的构件存在.同时,存在大量独立于应用领域的计算机特定的软件构件,如:程序设计语言的类库,函数库,VBX,OCX,用户界面构件等.但对大多数特定领域来说,可复用构件仍十分短缺,从而形成了一个巨大的应用软件构件市场.
软件复用技术将促进软件产业的变革,使软件产业真正走上工程化,工业化的发展轨道
.软件复用将造成软件产业的合理分工,专业化的构件生产将成为独立的产业而存在,软件系统的开发将由软件系统集成商通过购买商用构件,集成组装而成.软件复用所带来的产业变革将会带来更多的商业契机,形成新的增长点.
在当前的情况下,我国的软件产业发展一定要结合国情,抓住机遇.软件
构件技术的应用
,正在促进软件产业改革和重组分工,这对我国软件产业的发展是一个良好的机遇.我国正在大力加强国家信息化工作,具有广大的信息市场.由于具体的国情,大多数信息系统的开发工作是由国内公司承担,因此,也就培养了一大批领域专家,为推行软件构件技术,发展软件构件生产业奠定了良好的基础.同时,在构件技术方面,多年的攻关研究已使我们具有良好的技术积累.我们应在国家支持下,在行业部门的领导下,以政府或行业行为的方式推广软件构件技术,促进软件构件企业的发展.我国已失去了较多的信息产品市场,目前,正面临振兴的机遇,如何抓住机遇,也是严峻的挑战.
在软件产业的发展策略上,应由政府或行业主管部门组织构件标准规范的制定和发布;选择若干领域进行软件构件技术的推广和软件构件企业建设的试点工作,推行基于构件-构架模式的软件生产线的工程化,工业化软件生产技术;加快软件复用和软件构件技术的普及,培训工作,培养一批高质量的领域分析员队伍;制定合理措施及政策,激励软件构件技术的采用和推广;建立软件风险投资机制和软件生产基金,激励构件专门企业的形成和零散构件的开发;尽快完成试点工作,及早进军国际应用构件市场.
参考文献
[Brownsword 96] Lisa Brownsword, Paul Clements, “A Case Study in Successful Product Line Development”, Technical Report, CMU/SEI-96-TR-016, October 1996
[Caldiera 91] Caldiera, V. R. Basili, “Identifying and Qualifying Reusable Software Components”, IEEE Computer, vol.24, no. 2, pp. 61-70, Feb. 1991
[Cohen 92] Sholom G. Cohen, Jay L. Stanley, Jr., A. Spencer Peterson, Robert W. Krut, Jr., “Application of Feature-Oriented Domain Analysis to the Army Movement Control Domain”, Technical Report, CMU/SEI-91-TR-28, ESD-91-TR-28, June 1992
[Cohen 96] Sholom Cohen, Seymour Friedman, Lorraine Martin, Tom Royer, Nancy Solderitsch, Robert Webster, “Concept of Operations for the ESC Product Line Approach”, Technical Report, CMU/SEI-96-TR-018, September 1996
[Feiler 93] Peter H. Feiler, “Reengineering: An engineering problem,” Technical Report CMU/SEI-93-SR-5, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 1993
[Foreman 97] John Foreman, Kimberly Brune, Patricia McMillan, Robert Rosenstein, “Software Technology Review”, CMU/SEI, June 1997
[Garlan 93] David Garlan, Mary Shaw, “An Introduction to Software Architecture”, Advances in Software Engineering and Knowledge Engineering, volume I, World Scientific Publishing, 1993
[Microsoft 95] Microsoft Corporation, “The Component Object Model Specification”, Version 0.9, October 24, 1995 [online]. Available WWW (1995)
[Microsoft 96] Microsoft Corporation, “Distributed Component Object Model Protocol COM/1.0”, draft, November 1996 [online]. Available WWW (1996)
[Mili 95] Hafedh Mili, Fatma Mili, and Ali Mili, “Reusing Software: Issues and Research Directions”, IEEE Transactions on Software Engineering, Vol. 21, No. 6, pp. 528-562, June 1995
[NATO 91a] NATO, “NATO Standard for Developing Reusable Software Components”, Vol. 1 of 3 volumes, NATO contact number CO-5957-ADA, 1991
[NATO 91b] NATO, “NATO Standard for Management of a Reusable Software Component Library”, Vol. 2 of 3 volumes, NATO contact number CO-5957-ADA, 1991
[NATO 91c] NATO, “NATO Standard for Software Reuse Procedures”, Vol. 3 of 3 volumes, NATO contact number CO-5957-ADA, 1991
[OMG 96] Object Management Group home page [online]. Available WWW (1996)
[Petro 95] James Petro, Michael E. Fotta, David B. Weisman, “Model-Base Reuse Repository – Concepts and Experience”, Proc. Seventh International Workshop on CASE, July 10-14, 1995, Toronto, Ontario, Canada, Edited by Hausi A. Muller & Ronald J. Norman, pp. 60-69, IEEE Computer Society Press, Los Alamitos, California, USA
[Prieto-Diaz 93] Ruben Prieto-Diaz, “Status Report: Software Reusability”, IEEE Software, Vol. 10, No. 3, May 1993, pp. 61-66
[RIG 93] RIG, “Basic Interoperability Data Model (BIDM)”, RPS-0001, Reuse Library Interoperability Group, April, 1993
[RIG 94] RIG, “Uniform Data Model for Reuse Libraries (UDM)”, RPS-0002, Reuse Library Interoperability Group, January, 1994
[STARS 92] STARS, “Asset Library Open Architecture Framework Version 1.2” Informal Technical Report STARS-TC-04041/001/02, 1992/8
[Tracz 95] Will Tracz, “Confessions of a Used Program Salesman – Institutionalizing Software Reuse”, Addison-Wesley Publishing Co., New York, NY, April 1995
1.1 基本概念
复用概念的第一次引入是在1968年NATO软件工程会议上McIlroy的论文”大量生产的软件构件”中
.在此以前,子程序的概念也体现了复用的思想.但其目的是为了节省当时昂贵的机器内存资源,并不是为了节省开发软件所需的人力资源.然而子程序的概念可以用于节省人力资源的目的,从而出现了通用子程序库,供程序员在编程时使用.例如,数学程序库就是非常成功的子程序复用的例子.
在其后的发展过程中,有许多复用技术的研究成果和成功的复用实践活动.但是,复用技术在整体上对软件产业的影响却并不尽如人意.
这是由于技术方面和非技术方面的种种因素造成的,其中技术上的不成熟是一个主要原因.近十几年来,面向对象技术出现并逐步成为主流技术,为软件复用提供了基本的技术支持.软件复用研究重新成为热点,被视为解决软件危机,提高软件生产效率和质量的现实可行的途径 [Mili 95].
软件复用是指重复使用”为了复用目的而设计的软件”的过程 [Tracz 95].
相应地,可复用软件是指为了复用目的而设计的软件.与软件复用的概念相关,重复使用软件的行为还可能是重复使用”并非为了复用目的而设计的软件”的过程,或在一个应用系统的不同版本间重复使用代码的过程,这两类行为都不属于严格意义上的软件复用.
在软件演化的过程中,重复使用的行为可能发生在三个维上:
时间维:使用以前的软件版本作为新版本的基础,加入新功能,适应新需求,即软件维护.
平台维:以某平台上的软件为基础,修改其和运行平台相关的部分,使其运行于新平台,即软件移植.
应用维:将某软件(或其中构件)用于其他应用系统中,新系统具有不同功能和用途,即真正的软件复用.
这三种行为中都重复使用了现有的软件,
但是,真正的复用是为了支持软件在应用维的演化,使用”为复用而开发的软件(构件)”来更快,更好地开发新的应用系统.
分析传统产业的发展,其基本模式均是符合标准的零部件(构件)生产以及基于标准构件的产品生产(组装),其中,
构件是核心和基础,”复用”是必需的手段.
实践表明,这种模式是产业工程化,工业化的必由之路.标准零部件生产业的独立存在和发展是产业形成规模经济的前提.机械,建筑等传统行业以及年轻的计算机硬件产业的成功发展均是基于这种模式并充分证明了这种模式的可行性和正确性.这种模式是软件产业发展的良好借鉴,软件产业要发展并形成规模经济,标准构件的生产和构件的复用是关键因素.这正是软件复用受到高度重视的根本原因.
软件复用可以从多个角度进行考察 [Prieto-Diaz 93].依据复用的对象,可以将软件复用分为产品复用和过程复用.
产品复用指复用已有的软件构件,通过构件集成(组装)得到新系统.过程复用指复用已有的软件开发过程,使用可复用的应用生成器来自动或半自动地生成所需系统.
过程复用依赖于软件自动化技术的发展
,目前只适用于一些特殊的应用领域.
产品复用是目前现实的,主流的途径.
依据对可复用信息进行复用的方式,可以将软件复用区分为
黑盒(Black-box)复用和白盒(White-box)复用
.黑盒复用指对已有构件不需作任何修改,直接进行复用.这是理想的复用方式.白盒复用指已有构件并不能完全符合用户需求,需要根据用户需求进行适应性修改后才可使用.而在大多数应用的组装过程中,构件的适应性修改是必需的.
1.2 复用意义
通常情况下,
应用软件系统的开发过程包含以下几个阶段:需求分析,设计,编码,测试,维护等
.当每个应用系统的开发都是从头开始时,在系统开发过程中就必然存在大量的重复劳动,如:用户需求获取的重复,需求分析和设计的重复,编码的重复,测试的重复和文档工作的重复等.
探讨应用系统的本质,可以发现其中通常包含三类成分:①通用基本构件:是特定于计算机系统的构成成分,如基本的数据结构,用户界面元素等,它们可以存在于各种应用系统中;②领域共性构件:是应用系统所属领域的共性构成成分,它们存在于该领域的各个应用系统中;③应用专用构件:是每个应用系统的特有构成成分.
应用系统开发中的重复劳动主要在于前两类构成成分的重复开发.
软件复用是在软件开发中避免重复劳动的解决方案,其出发点是应用系统的开发不再采用一切”从零开始”的模式,而是以已有的工作为基础,充分利用过去应用系统开发中积累的知识和经验,如:需求分析结果,设计方案,源代码,测试计划及测试案例等,从而将开发的重点集中于应用的特有构成成分.
通过软件复用,在应用系统开发中可以充分地利用已有的开发成果,消除了包括分析,设计,编码,测试等在内的许多重复劳动,从而提高了软件开发的效率,同时,通过复用高质量的已有开发成果,避免了重新开发可能引入的错误,从而提高了软件的质量.
1.3 关键因素
软件复用有三个基本问题,一是必须有可以复用的对象,二是所复用的对象必须是有用的,三是复用者需要知道如何去使用被复用的对象
.软件复用包括两个相关的过程:
可复用软件(构件)的开发(Development for Reuse)和基于可复用软件(构件)的应用系统构造(集成和组装)(Development with Reuse).
解决好这几个方面的问题才能实现真正成功的软件复用.
与以上几个方面的问题相联系,
实现软件复用的关键技术因素主要包括:软件构件技术(Software Component Technology),领域工程(Domain Engineering),软件构架(Software Architecture),软件再工程(Software Reengineering),开放系统(Open System),软件过程(Software Process),CASE技术等.
除了上述的技术因素以外,
软件复用还涉及众多的非技术因素
,如:机构组织如何适应复用的需求;管理方法如何适应复用的需求;开发人员知识的更新;创造性和工程化的关系;开发人员的心理障碍;知识产权问题;保守商业秘密的问题;复用前期投入的经济考虑;标准化问题等等.
实现软件复用的各种技术因素和非技术因素是互相联系的.它们结合在一起,共同影响软件复用的实现.
2 软件复用的核心技术–软件构件技术
原则
软件开发是一门综合性学科,它包括哲学,基础科学,技术科学,工程管理四个知识层次
.哲学决定着整个学科建立的指导思想,认识论和世界观.认识论就是人们认识客观世界的规律和方法,我们称它为认知体系.
应用软件开发时,有自己必须遵循的哲理和认知观,对基础理论,研究方向以及采用的技术措施起着指导作用,符合学科就能发展,否则就会遇到各种问题,甚至导致失败.从软件发展的几个里程碑中可看出,认知观起到了决定性的作用.
软件开发的初期阶段,我们称为程序设计时代,软件开发处于小作坊个体生产方式水平.到了60年代中期,出现了一些大型复杂的软件系统,人们认识到以个人的能力难以完成一个大系统的任务.W.E.Dijkstra 首先提出了一种解决方案,采用结构程序设计方法,就是把软件开发看作数学求解,沿用数学上的枚举,抽象,归纳,类比等思维方式,把问题简化.用工程的概念,方法,原理和技术来开发和维护软件,产生了结构化分析和设计的方法.这种开发方法长期左右着我国的软件开发,无疑起到了重要作用,然而它仍然存在着认知上的缺陷,如开发周期长,成本高,质量差,特别是所开发的软件不能适应系统的不断演化.
到70年代,人们认识到,仅从软件结构上脉络清晰是远远不够的,这只是”表”,不是”里”,软件在结构上还应该适应客观世界的自然结构.M.A.Jackson认为应用软件应该忠于现实,高于现实,提出JSD系统开发方法,其指导思想是”仿真客观世界”,采用自底后上的设计步骤.JSD方法第一次揭示了客观世界与软件系统之间的关系,因而所开发的软件悟性好,实用性强.然而JSD方法也存在着固有的缺陷:如何仿真要确定系统的实体和活动,它没有给出准则可循;没有区分客观世界的模型和软件系统模型,不能直接映射过去,其结果是系统结构混乱,效率低,软件成份复用性差.
到了80年代,面向对象重新崛起,面向对象的认识论是将系统看成由多个对象组成,通过对象之间的通信形成了系统,为客观世界过渡到软件系统提供了途径和编程的思维方法.
其主要特征是:(1) 类和封装性,实现数据抽象和信息隐蔽,给出了对象类型和参数化,通过生成实例后组装成系统,提供了实现复用的手段.(2) 继承性,提高了代码复用性.(3) 多态性.
面向对象给出了软件系统的体系结构,引入了软件复用的思维方法.近年来引起了越来越多的人关注,提出了多种对象模型,语言,设计了各种基类型库,使得面向对象程序设计逐步成为热点.
问题
面向对象技术虽然被大家接受,公认为当前的发展主流,然而在实际应用时,还存在着一系列问题.
(1) 模型和概念尚未统一,不同的人对系统和对象的理解不一致,导致了各种对象语言均有很大差异,且语言自身与纯面向对象理论有许多不一致的地方,就难以形成统一的标准和开发规范.
(2) 要求使用面向对象技术的人员素质较高,要掌握的东西很多,如要熟练掌握C++必需了解大量的MFC类库,且要了解每个类的细节.
(3) 面向对象复用仅仅是处于初级阶段,未提出任何模式和规范以及相应的管理机制.
(4) 工程上难以实施.目前面向对象能很好应用的领域有限(如VB的界面设计,多媒体软件设计),真正用纯面向对象技术来开发大型软件的并不多,其原因有:如何提炼对象类,采用OOA是不可行的;实际应用领域中的可复用领域专用构件缺乏;由于对象无统一标准,因此还停留在程序员自己复用,很难共享,更谈不上分布式情况下复用;纯面向对象要摒弃原有的许多技术等.产生上述问题的根本原因是由于认知体系上的不完整.由此基于面向对象的构件软件应运而生.
概念
构件(component)简单地说是可复用的软件组成成份,可被用来构造其他软件.构件(Component)是指应用系统中可以明确辨识的构成成分.而可复用构件(Reusable Component)是指具有相对独立的功能和可复用价值的构件
.它可以是被封装的对象类,类树,一些功能模块,软件
框架
(framwork),软件构架(或体系结构Architectural),文档,分析件,设计模式(Pattern)等.构件分为构件类和构件实例,通过给出构件类的参数,生成实例,通过实例的组装和控制来构造相应的应用软件.
可复用构件应具备以下属性 [Tracz 95]:①有用性(Usefulness):构件必须提供有用的功能;②可用性(Usability):构件必须易于理解和使用;③质量(Quality):构件及其变形必须能正确工作;④适应性(Adaptability):构件应该易于通过参数化等方式在不同语境中进行配置;⑤可移植性(Portability):构件应能在不同的硬件运行平台和软件环境中工作.
随着对软件复用理解的深入,
构件的概念已不再局限于源代码构件,而是延伸到需求,系统和软件的需求规约,系统和软件的构架,文档,测试计划,测试案例和数据以及其他对开发活动有用的信息.这些信息都可以称为可复用软件构件.
软件系统的复杂性不断增长,软件从业人员的频繁流动和同行之间的激烈竞争迫使软件企业提高软件质量,积累和固化知识财富,并尽可能缩短软件产品交付时间.集软件复用,分布式对象计算,CASE和企业级应用程序开发(EAD)等技术为一体,”
基于构件的软件开发
“(Component-Based Software Development,简称CBSD或CBD)以软件构架为组装蓝图,以可复用软件构件为组装预制块,支持组装式软件复用,是提高软件生产效率和产品质量,减轻人员流动副作用,缩短产品交付时间的现实有效的途径之一.
CORBA,Microsoft Visual Studio,UML,UNIFACE,Oracle8,三层结构,JavaBean,ActiveX,…,几乎所有的软件开发新技术和新产品都高唱CBD的主题,以自己的理解为下一代软件开发提供技术支持.尽管CBD涉及软件开发的方方面面,但是其核心技术和难点都集中在构件构架技术上.经过几年的发展,构件本身的模型及其规范已经提出,较有影响是OLE的COM及CORBA的SOM.目前已发展到分件式构件规范,主要有CORBA,OLE/ActiveX和JaveBeans,其发展日趋明朗,最终将会趋向统一.
为了更好地了解构件的性质,我们把它按多个侧面进行分类:(1) 按开发过程构件分为分析件,设计件,程序件和数据件.(2) 按功能分,分为三层:基础层为基本数据类构件和系统支撑构件;中间层为各种通用的中间件,顶层为针对领域的专用构件或子系统构件,从粒度上看,通常底层的粒度为较小,而顶层的粒度为较大.(3) 按使用方式分为动态和静态两种.(4) 按构件的结构分为原子构件及由多个构聚集的组合构件.
技术
软件构件技术是支持软件复用的核心技术
,是近几年来迅速发展并受到高度重视的一个学科分支.其主要研究内容包括:
构件获取:有目的的构件生产和从已有系统中挖掘提取构件;
构件模型:研究构件的本质特征及构件间的关系;
构件描述语言:以构件模型为基础,解决构件的精确描述,理解及组装问题;
构件分类与检索:研究构件分类策略,组织模式及检索策略,建立构件库系统,支持构件的有效管理;
构件复合组装:在构件模型的基础上研究构件组装机制,包括源代码级的组装和基于构件对象互操作性的运行级组装;
标准化:构件模型的标准化和构件库系统的标准化.
应用
根据IDG和Gartner等组织的预测,今后,软件开发商必须了解主要系统集成商和应用软件开发人员所需要的基本构件,因为他们在引导着构件技术的需求和功能走势.到2001年,所有新开发的应用至少有60%将是基于构件的组装,开发商的市场应变能力也因此得到提高.围绕构件的生产,管理和组装将形成具有相当规模的构件市场和CBD工具市场.随着应用的推广和深入,对构件组装技术,软件构架技术,分析设计构件的描述和复用,特定领域软件构架,构件库部署等问题的研究也会不断发展.
以面向对象为基础而发展起来的软件构件技术,摆脱了面向对象的理论束缚,目前理论上还未完善,但实际应用却有较大进展.在国内,构件软件的理论和实际工程已被人们普遍关注.在理论上,北京大学,中科院软件所,吉林大学,南京大学,复旦大学,中山大学等单位,均发表了不少有价值的学术论文.在实际工程上,青鸟公司,中软公司,华科电脑公司,特宝科公司,天中公司等均采用
基于构件技术
开发应用软件,积累了不少经验,获取极好的效益.预计在不久的将来,构件软件技术将会在全国普遍开花.构件软件技术还处于发展阶段,目前迫切需要解决以下问题:针对如何开发应用,需要有一套开发规范和质量保证体系;如何提取领域构件,仍然是处于摸索阶段.开始时,我们是采用通过功能划分来提取构件,这就影响构件的可复用性,目前可以采用领域中的模型和各种设计模式来提取构件是一条好的途径,但还未总结出可操作的规程;最后鉴于分布式系统网络系统和多媒体应用,国际上的复合文档和Java正处于迅速发展时期,在我国还缺乏实际应用的经验.
以下,将对构件模型与构件描述语言,构件的获取,构件的表示和检索,构件组装,软件构架技术和构件库的标准化等方面进行简要的介绍.
2.1 构件模型和构件描述语言
研究构件软件的两个核心是:如何提取可复用构件以及如何组装成系统并能实现互操作.
目前讨论的软件体系结构,构件模型,均是为解决构件之间的接口,实现互操作.近年国际已提供了各种构件库,如MFC,PBL,VBL等等.但是这类类库绝大多数属于基本数据类库,制作界面的控件,各种中间件,支撑件及系统件等类库.但是离要集成应用软件所需要的构件还有很大距离.虽然国际上各种软件公司正在开发各种中间件产品或领域构件,但常常是不能拿来就用,如开发MIS系统时的Form操作构件,查询统计构件以及报表生存构件,特别是一些与领域有关的专用构件,必须要自己开发.那
么如何提取领域构件,国际上还没有一种可循的办法,也就是说我们在开发应用软件的同时,难以形成相应的领域构件,以便适应系统自身演化或可复用到同领域中的不同系统的开发中.
实现CBD必须首先回答”
构件是什么
“的问题,建立或采纳标准化的构件模型.构件模型定义了构件的本质属性,规定了构件接口的结构以及构件与软件构架,构件与构件之间的交互机制.构件模型通常还提供创建和实现构件的指导原则.CBD工具可以识别和组装来自不同开发者的符合同一构件模型的构件.一个被所有构件生产者和构件复用者所接受的构件模型实际上起到了构件标准化的作用.
在学术界和产业界已经出现了多种构件模型,其中”3C”模型是学术界普遍认同的一个具有指导性的构件模型.该模型从概念(concept),内容(content)和语境(context)三个不同方面来描述构件:
概念 – 关于”构件做什么”的抽象描述,可以通过概念去理解构件的功能.概念包括接口规约和语义描述两个部分;
内容 – 概念的具体实现,描述构件如何完成概念所刻划的功能;
语境 – 构件和外围环境在概念级和内容级的关系.语境刻划构件的应用环境,为构件的选用和适应性修改提供指导.
而DCOM/COM+,JavaBean/Enterprise JavaBean和CORBA构件模型三足鼎立,构成了实现级构件模型工业标准的竞争与互操作并存的格局.现有的构件模型一般认为构件由构件接口(对应于3C模型中的概念和概念级语境)和构件内容两部分组成.构件接口就是为成功复用该软件实体而需要提供给外界的所有信息,包括构件向外提供的和请求的服务,构件的自述信息和定制信息,构件的初始化,实例化和永久化方法以及构件对目标复用环境的依赖和构件组装信息等;构件内容就是用于直接复用的软件实体,它可以具有源代码,二进制码,文档,分析设计模型和脚本等不同的物理形态,并遵从一定的格式标准.
构件是为了复用,就必需遵循一定的规范,通过语言的功能来实现规范是一种极好手段.按照应用软件开发过程,可以提供下述语言.
(1) 构件描述语言,用来描述构件的规格说明,即描述设计件;也可用来检索已有的可复用构件,是设计构件检索语言的依据.
(2) 构件编程语言.可以采用现在流行的各种编译程序,如VC,VB,Java等.
(3) 过程控制语言和系统集成.通过过程控制来制作专用构件,子系统构件和应用软件,要提供连接和嵌入的功能,还要包括面界开发功能,构件库的管理和实例生成,要提供数据库设计和数据库连接的功能,还提供大量的基本构件,中间构件及APL.如PB,Delphi等.由于PB易于掌握,除提供上述功能外,又能用于编程和构件管理,它通过不断版本更新,能紧跟新技术的发展,因此普遍受到软件开发者的青睐.
建立在构件模型的基础上,构件描述语言(Component Description Language)以一种严格而又易于理解的方式,为协作构件,构件组装工具和CBD开发人员提供全面准确的构件信息.构件描述语言是从70年代的模块互联语言MIL,80年代的构件描述语言CDL和90年代的构架描述语言ADL发展而来的.CDL的基本思想是将构件视为黑盒,通过描述构件接口的语法和语义向外界提供构件的结构和行为信息,使构件复用者不必关心其内部细节.CORBA IDL,DCOM ODL和IDL等接口描述(或定义)语言都能够描述构件接口的语法,并且具备编译和浏览工具的支持;但是现有的接口描述语言在描述构件接口语义和构件间复杂的交互协议方面缺乏进一步的支持.
针对基于构件的应用软件开发过程,中科院软件所仲萃豪等人提出了三个阶段的生命周期,即软件开发模型.
数据库设计时分为概念设计,逻辑设计和物理设计三个阶段,应用软件开发过程也分三个阶段.
第一阶段为需求获取,采用仿真办法,描述客观世界的人工系统.在八?五时期,他们试验成功了”角色法”的描述方法,设计出领域需求报告可复用构件,用HIPO图,半形式方式描述出客观系统.
第二阶段是分析客观系统,设计出逻辑系统,称为领域分析.由于客观系统和软件系统在概念,结构,功能,通信方式均有很大差异,虽然都是采用面向对象的概念来形成,但客观世界的对象是实体,没有类的概念;客观世界是一种功能模型,而软件系统是面向封装后的对象组成.要把从客观系统转换到软件系统,且要有利于实现复用,为此他们提出了一种过渡用的软件系统,把与领域有关的不变部分和可变部分分开,设计出领域软件的
框架
,提取出领域软件,设计出主题数据库,由此形成了与领域有关的逻辑系统,以上各部分结果,我们统称为设计件.
在开出构件的规格说明后,就可以编制构件类,构件类树,为实现领域的群体开发作好一切文档准备.
第三阶段为系统集成,找到合适构件类,将其生成实例,用过程控制语言描述出系统中的各子系统;配置用户喜爱的操作界面;生成各种输入输出构件实例等.最后集成系统,通过实际运行,不断修改,直到用户完全满意为止,这种方法也能适应今后系统的演化.一旦领域软件系统形成后,在开发同一领域的应用软件时仅仅是第三阶段的工作,用户自己可以来完成,维护工作也大大减轻.
上述开发过程中,软件开发人员可以分工去做.先由咨询公司或软件公司完成第一,第二阶段工作,由软件产品开发公司完成逻辑系统,提供领域分析的设计件,领域专用或通用的构件类库以及系统集成专用平台,再由集成公司或用户自己来完成第三阶段工作.
2.2 构件的获取
构件模型和软件构架为基于构件的软件开发奠定了基础,但是在实际应用CBD技术时还必须具备大量可供选择的可复用构件.构件的获取手段有多种,既可以商业采购得到COTS(Commercially-Off-The-Shelf)构件(如开发环境中自带的ActiveX控件和Delphi构件),也可以利用项目承包商和合作伙伴开发的NDI构件(Non-Developmental Item),或者在领域工程和再工程的基础上从已有应用系统中发掘和提炼可复用构件,或者针对新需求和新技术从头自主开发新构件.不论以何种方式获得的构件,都必须经过严格的测试和认证,在构件库中统一管理.对于外来构件,除了要考察其质量和可用性,还必须考虑日后构件维护和版本升级的成本.
伴随一种构件模型的提出,应该同时提供构件开发和封装工具,或者一整套构件开发和构件组装的指导原则,为构件开发者提供工具辅助和技术支持.构件开发者则利用特定领域的开发经验制作能够满足领域普遍需求的可复用构件.目前市场上已经有大量面向GUI,数据库和网络的VBX与ActiveX控件,JavaBean和Delphi构件,以及众多的类库,DLL接口和API,这些源代码和目标码构件大大提高了程序员的工作效率.但遗憾的是,具有更高复用价值的分析设计构件以及面向特定应用领域(而不是计算机领域)的业务构件还非常少见.
2.3 构件的表示和检索
构件的表示和检索机制的研究一直是构件库研究的热点:一方面,拥有大量可复用构件的组织必须以一种易于分类管理而又方便复用者检索的机制来表示和保存构件资产;另一方面,有效的构件检索机制能够降低构件查找和理解的成本,而构件的合理表示和分类正是实现高效方便的检索的基础.
目前有很多构件分类和检索方法,从构件表示出发可以分为人工智能方法,超文本方法和信息科学方法三类;而根据复杂度和检索效果的不同则可以分为基于文本的,基于词法描述子的和基于规约的编码和检索.信息科学方法是实际复用项目中应用较为成功的一类,并且以枚举,刻面,属性值,关键词和正文检索几种方法较为常见,其中刻面分类方法能够表达丰富的构件信息,尤其为人关注.刻面分类(Faceted Classification)方法将关键词(术语)置于一定的语境中,并从反映构件本质特性的不同视角(刻面)将构件分类.每个刻面中有一组术语(关键词),术语间由于有一般特殊关系和同义词关系而形成结构化的术语空间.构件的描述术语仅限在给定的刻面之中选取.在术语空间中游历可以帮助复用者理解相关领域.术语空间可以演变.
2.4 构件组装
基于构件的开发通过构件组装得到最终应用系统,构件组装必须以某个
框架
或构架为蓝图,实际可以看作是用构件实例将软件构架具体化的过程.构件组装技术以构件模型,构件-构架描述和开放系统技术为基础,成功的组装必须以开放构件模型和规范的构架描述(包括对构件连接和交互协议的严格定义)为基础,构件实例必须符合系统中其他部分的要求.分布式软件总线,事件登记和回调,构架描述语言,脚本语言和代码生成技术都为构架组装指出了希望之路,DCOM,JavaBean等运行级的分布式构件模型的出现和ORB与Internet的引入,使构件之间的独立性和互操作性变得更强,这些技术为构件组装,尤其是运行级的构件组装提供了有力的支持.
基于控件的GUI构造和4GL工具可以被组装工具的成功范例,但目前仍然缺乏通用的构件组装方法.一个可用的构件组装工具应该具有构件的浏览和定制,构件的图形化表示和操纵,以及目标系统(半)自动生成等功能.真正意义上的CBD应该在分析,设计,实现和系统部署等不同阶段,在函数,对象,模块,
框架
,服务进程和程序等不同粒度上,从构件构架的开发,描述,浏览,插装,定制等不同方面对构件组装提供全面的支持.
2.5 构件及构件库的标准化
美国军方与政府资助的项目中,已建立了若干构件库系统,如CARDS,ASSET,DSRS等.由DARPA发起,由美国军方,SEI和MITRE支持的STARS项目在此基础上考虑了开放体系结构的构件库之间共享资源和无缝互操作的问题,并于1992年提交了ALOAF(Asset Library Open Architecture Framework,开放体系结构的构件库
框架
)Version1.2版本.这一报告体现了STARS对可复用构件库系统的认识,给出了一个构件库
框架
的参考模型,并就此实现了ALOAF规约作为该参考模型的实例,由此证明以公共
元模型
为基础,在构件库之间交换信息和创建易于移植的复用工具是可能的和必要的.
ALOAF的短期目标是尽快实现不同复用库间的构件共享,长期目标是实现异质构件库间的无缝互操作,包括构件及其描述的共享及丰富的构件库工具集的易移植性.其基本观点是软件系统的开发将演化成一种过程驱动的,特定于领域的和基于复用的技术支持范型.STARS认为构件库是软件工程环境(SEE)的子系统之一,其提供的功能应与SEE
框架
的参考模型一致.构件库系统利用SEE提供的服务,并向上层提供服务.ALOAF更关注构件库
框架
而非更广泛的SEE
框架
.ALOAF包括构件库参考模型及其服务规约和数据描述规约.ALOAF在构件库和复用服务方面对SEE参考模型进行补充.
可复用库互操作组织(Reuse library Interoperability Group,缩写为RIG)是一个志愿的基于一致意见的组织,由来自政府,学校和私人企业的成员组成.RIG认为,当前几乎没有有效的方法在众多的政府和企业界软件复用库间共享软件构件,其结果是低效和不必要的冗余.可互操作性,即复用库间软件构件的共享,可能是在短期内提高效率,增加复用库的价值和影响,并在长期中避免不兼容协议的爆炸性增长的关键.因此,RIG的目标是致力于开发可互操作性的解决方案.RIG的成果包括BIDM和UDM [RIG 93] [RIG 94].UDM是基于ALOAF的三层数据模型的统一数据模型.BIDM是UDM的一个子集,定义了为了实现互操作,复用库交换软件构件时所需的信息的最小集.BIDM已被IEEE采纳为标准.
北大西洋公约组织(NATO)针对NATO,NATO参与国和承包商制定了一组关于软件复用的标准,其中包括”可复用构件开发标准”,”可复用软件构件库管理标准”,”软件复用过程标准” [NATO 91a] [NATO 91b] [NATO91c]. 制订这些标准的目标是供NATO及其参与国的项目管理部门使用它们来建立复用计划需求和向承包商提供指导.承包商则将它们用于特定项目的开发实践.
2.6 构件组装技术
CORBA是公共对象请求代理体系结构(Common Object Request Broker Architecture)的缩写,是对象管理组织(OMG)开发的一套分布式对象技术标准,涉及接口,注册,数据库,通信和出错处理等方面的问题 [OMG 96].和对象管理体系结构(OMA)定义的其他对象服务相结合,CORBA成为支持分布式系统中对象技术的中间件设施.CORBA的对象请求代理(ORB)作为转发消息的中间件,实现了对象间的无缝集成和互操作.因此,CORBA可作为面向对象的软件构件在运行级上组装的技术基础,从而实现构件的黑盒复用.当前已有许多符合CORBA的ORB产品,如ORBIX,NEO,VisiBroker,PowerBroker,SmallTalkBroker,SOM/DSOM,DAIS,NonStop等.
OLE是微软公司开发的支持对象连接嵌入的机制,其初旨是解决复合文档问题 [Microsoft 95].OLE为构件对象的互操作提供了基础支持,因此,也为构件的黑盒复用提供了技术基础.OLE是主要的不符合CORBA标准的对象连接中间件.DCOM是微软公司开发的分布式构件对象模型,支持分布式系统中的面向对象技术 [Microsoft 96].
JAVA是近几年随着WEB风行全球而发展起来的一种新语言.它是一种纯OO的语言,外观象C++,内核类似Smalltalk.JAVA和WEB的结合带来了移动的对象,可执行的内容等关键概念.JAVA具有体系结构中立的特性,从而使得JAVA程序可不需修改甚至重编译而运行于不同平台之上.JAVA的新版还加入了远程方法调用(RMI)的特性,在效果上,RMI提供了类似CORBA的ORB的功能.JAVA的这些特性使其成为软件构件技术的良好支持工具.用JAVA书写的构件将具有平台独立性和良好的互操作性.
这些技术的流行为构件组装提供了很好的技术支持,同时它们也为构件提供了实现标准.软件复用和分布对象技术的结合使得即插即用的构件黑盒组装成为可能.
3 复用的其它相关技术
3.1 领域工程
从软件开发过程的角度看,有关软件复用的问题可以分为两类,一类是关于面向复用的开发(Development for Reuse),另一类是关于基于复用的开发(Development with Reuse).
第一类问题主要是关于如何产生具有较高可复用性的构件或生成过程,第二类问题包含三个方面,即:如何找到可复用构件,如何判断可复用构件是否符合当前需要,以及如何对可复用构件进行适应性修改 [Mili 95].领域工程有助于这些问题的解决,从而对软件复用提供了有力的支持.
领域工程有助于产生具有较高可复用性的构件.领域工程将关于领域的知识转化为领域中系统共同的规约,设计和构架,使得可以被复用的信息的范围,扩大到了抽象级别较高的分析和设计阶段.由于通过领域工程产生的可复用构件来源于领域中现有的系统,体现了领域中系统的本质需求,因此这些构件具有较高的可复用性 [Prieto 87].
同时,领域工程产生了领域模型和特定领域的软件构架(DSSA)或应用系统的生成过程,这对于基于复用的开发很有帮助.可复用构件是根据领域模型和DSSA组织的,方便了构件的检索.开发以领域模型和DSSA为线索进行,可以帮助开发者识别复用机会,判断可复用构件是否符合当前需要.DSSA为构件组装提供了上下文,使得利用可复用构件组装或生成新的系统较为容易.
领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程,它覆盖了建立可复用的软件构件的所有活动[Tracz 95].其中”领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域.
领域工程对领域中系统的进行分析,识别这些应用的共同特征和可变特征,对刻划这些特征的对象和操作进行选择和抽象,形成领域模型,依据领域模型产生出领域中应用共同具有的体系结构(即特定领域的软件构架,缩写为DSSA)或生成过程,并以此为基础识别,开发和组织可复用构件 [Prieto 90].这样,当开发同一领域中的新应用时,可以根据领域模型,确定新应用的需求规约,根据特定领域的软件构架形成新应用的设计,并以此为基础选择可复用构件进行组装,从而形成新系统.
领域工程包括三个主要的阶段:
领域分析:这个阶段的主要目标是获得领域模型(Domain Model).领域模型描述领域中系统之间的共同的需求 [Petro 95].这个阶段的主要活动包括确定领域边界,识别信息源,分析领域中系统的需求,确定哪些需求是被领域中的系统广泛共享的,哪些是可变的,从而建立领域模型.
领域设计:这个阶段的目标是获得领域构架(Domain-Specific Software Architecture,缩写为DSSA).DSSA描述在领域模型中表示的需求的解决方案,它不是单个系统的表示,而是能够适应领域中多个系统的需求的一个高层次的设计 [Petro 95].建立了领域模型之后,就可以派生出满足这些被建模的领域需求的DSSA.由于领域模型中的领域需求具有一定的变化性,DSSA也要相应地具有变化性.
领域实现:这个阶段的主要行为是定义将需求翻译到由可复用构件创建的系统的机制.根据所采用的复用策略和领域的成熟和稳定程度,这种机制可能是一组与领域模型和DSSA相联系的可复用构件,也可能是应用系统的生成器.
这些活动的产品(可复用的软件构件)包括:领域模型,领域构架,领域特定的语言,代码生成器和代码构件等.
在领域工程的实施过程中,可能涉及的人员包括 [Cohen 92]:
最终用户:使用某领域中具体系统的人员;
领域专家:提供关于领域中系统信息的人员,他应该熟悉该领域中系统的软件设计和实现,硬件限制,未来的用户需求及技术走向;
领域分析员:收集领域信息,完成领域分析并提炼出领域产品(可复用软件构件)的人员,他应该具有完备的关于复用的知识,并对分析的领域有一定程度的了解;
领域分析产品(构件,构架)的使用者:包括最终用户,应用系统的需求分析员和软件设计者.
研究实践表明,软件复用在特定领域内更容易获得成功.因此,领域工程受到高度重视,已有许多研究成果.
三个有代表性的工作是:
卡内基.梅隆大学的软件工程研究所(CMU/SEI)提出的面向特征的领域分析方法(Feature-Oriented Domain Analysis Method,缩写为FODA方法) [Foreman 97].它支持对某领域中系统共性和个性的发现,分析和文档记录.FODA的过程分为三个阶段:上下文分析(Context Analysis),领域建模(Domain Modeling),构架建模(Architecture Modeling).FODA方法已成功地应用于美国空军运动控制等领域.
在美国国防部高级研究项目署(ARPA)资助下,建立了”用于易修改的可靠系统的软件技术”项目,研究领域特定的,基于复用的软件工程技术,并建立了三个示范工程项目.美国空军电子系统中心与美国航空航天局合作建立了”可复用防务软件的中央档案库”项目,以促进国防项目中的软件复用.Will Tracz提出了领域构架方法(Domain-Specific Software Architecture,缩写为DSSA方法) [Tracz 95].在最高的级别上,该方法有五个阶段.每个阶段可以进一步划分为一些步骤或子阶段.每个阶段包括一组需要回答的问题,一组需要的输入,一组将产生的输出和验证标准.该方法的领域工程过程是并发的(concurrent),递归的(recursive)和反复的(iterative).或者可以说,它是螺旋型的(spiral).完成该过程可能需要对每个阶段经历几遍,每次增加更多的细节.
STARS领域分析过程(Domain Analysis Process)分准备领域信息,分类领域实体,导出领域模型,扩展模型并分类四个阶段,每个阶段用结构化分析与设计技术描述,使用SADT图 [Tracz 95].
3.2 软件构架
软件构架(又称软件体系结构)是对系统整体结构设计的刻划,包括全局组织与控制结构,构件间通讯,同步和数据访问的协议,设计元素间的功能分配,物理分布,设计元素集成,伸缩性和性能,设计选择等 [Garlan 93].
软件构架为CBD提供了构件组装的基础和上下文.
一个典型的软件构架是由系统中的构件,连接子和约束构成的配置格局.研究软件构架有利于发现不同系统的高层共性,保证灵活和正确的系统设计,对系统的整体结构和全局属性进行规约,分析,验证和管理.将构架作为系统构造和演化的基础,可以实现大规模,系统化的软件复用.
研究软件构架对于进行高效的软件工程具有非常重要的意义:通过对软件构架的研究,有利于发现不同系统在较高级别上的共同特性;获得正确的构架对于进行正确的系统设计非常关键;对各种软件构架的深入了解,使得软件工程师可以根据一些原则在不同的软件构架之间作出选择;从构架的层次上表示系统,有利于系统较高级别性质的描述和分析.特别重要的是,在基于复用的软件开发中,为复用而开发的软件构架可以作为一种大粒度的,抽象级别较高的软件构件进行复用,而且软件构架还为构件的组装提供了基础和上下文,对于成功的复用具有非常重要的意义.
软件构架研究如何快速,可靠地从可复用构件构造系统的方式,着重于软件系统自身的整体结构和构件间的互联.其中主要包括:软件构架原理和风格,软件构架的描述和规约,特定领域软件构架,构件向软件构架的集成机制等.
软件开发实际上是从问题域向最终解决方案逐步映射和转换的过程,而特定领域软件构架(DSSA)和软件构架风格(Architectural Style)分别从问题域和软件解决方案两个方向提供了若干经过考验的候选转换路径
.特定领域软件构架是一个领域中的所有应用系统所共有的体系结构,是针对领域模型中的领域需求给出的解决方案,也是识别,开发和组织特定领域可复用构件的基础.在国内外的金融,MIS,CIMS和军事等领域中都开始注意开发特定领域的软件构架和集成
框架
的重要性.体系结构风格则根据系统结构的组织模式确定了一组可以用于风格实例中的构件和连接子,以及它们的拓扑结构,组装规则以及局部和全局约束,从而定义了一个面向系统结构的构架家族.软件构架风格与面向对象的设计模式或
框架
一样,为设计经验的复用提供了技术支持.Client/Server,分层的体系结构(Layered),分布式对象计算(Distributed Object Computing),管道和过滤器(Pipe & Filter),黑板系统(Blackboard)等都是广泛使用的软件构架风格.
3.3 软件再工程
软件复用中的一些问题是与现有系统密切相关的,如:现有软件系统如何适应当前技术的发展及需求的变化,采用更易于理解的,适应变化的,可复用的系统软件构架并提炼出可复用的软件构件 现存大量的遗产软件系统(Legacy Software)由于技术的发展,正逐渐退出使用,如何对这些系统进行挖掘,整理,得到有用的软件构件 已有的软件构件随着时间的流逝会逐渐变得不可使用,如何对它们进行维护,以延长其生命期,充分利用这些可复用构件 等等.软件再工程(Software Reengineering)正是解决这些问题的主要技术手段.
软件再工程是一个工程过程,它将逆向工程,重构和正向工程组合起来,将现存系统重新构造为新的形式 [Feiler 93].再工程的基础是系统理解,包括对运行系统,源代码,设计,分析,文档等的全面理解.但在很多情况下,由于各类文档的丢失,只能对源代码进行理解,即程序理解.
一个再工程的
框架
给出了进行一次再工程实践的全过程中所应当考虑的活动,它对人们如何对遗产系统进行再工程开发具有指导性意义.当然,一个这样的
框架
所给出的并不是一个需要严格遵守的活动规范,它所起的作用只是提醒人们在进行再工程的过程中需要注意哪些问题,而且针对不同的具体系统,可能会需要进行相应的修改才能适应具体问题的需求.
一个再工程的过程主要由决策分析,系统理解,和系统演化三个部分组成.
决策分析的活动包括:确定再工程活动的范围和方向;建立反映未来系统的质量提高的初始系统需求;对遗产系统的详细审查和分析等.决策的目的是在再工程,维护和新开发之间进行选择,决定是否要进行再工程.
如果决策分析决定进行再工程,就要开始对遗产系统进行系统理解.系统理解的功能是通过对遗产系统的源代码,设计记录以及其它文档资源的分析,得到对系统的全面而详细的信息,为从遗产系统到未来系统的转化提供坚实的基础.
对系统全面理解之后,就可以进行系统演化.系统演化通过对遗产系统的改造和重组,将之转化为未来系统.对于一个大的遗产系统,针对其不同部分和所期望的系统之间的距离,所使用的演化策略是不同的,主要可以有维护,改造和替换三种方法.
3.4 开放系统技术
开放系统技术的基本原则是在系统的开发中使用接口标准,同时使用符合接口标准的实现.这些为系统开发中的设计决策,特别是对于系统的演化,提供了一个稳定的基础,同时,也为系统(子系统)间的互操作提供了保证.开发系统技术具有在保持(甚至是提高)系统效率的前提下降低开发成本,缩短开发周期的可能.对于稳定的接口标准的依赖,使得开发系统更容易适应技术的进步 [Foreman 97].当前,以解决异构环境中的互操作为目标的分布对象技术是开放系统技术中新的主流技术.
开放系统技术为软件复用提供了良好的支持.特别是分布对象技术使得符合接口标准的构件可以方便地以”即插即用”的方式组装到系统中,实现黑盒复用.这样,在符合接口标准的前提下,构件就可以独立地进行开发,从而形成独立的构件制造业.
3.5 CASE技术
随着软件工程思想的日益深入人心,以计算机辅助开发软件为目标的CASE(Computer Aided Software Engineering)技术越来越为众多的软件开发人员所接受,CASE工具和CASE环境得到越来越广泛的应用.CASE技术对软件工程的很多方面,例如分析,设计,代码生成,测试,版本控制和配置管理,再工程,软件过程,项目管理等等,都可以提供有力的自动或半自动支持.CASE技术的应用,可以帮助软件开发人员控制软件开发中的复杂性,有利于提高软件开发的效率和质量.
软件复用同样需要CASE技术的支持.CASE技术中与软件复用相关的主要研究内容包括:在面向复用的软件开发中,可复用构件的抽取,描述,分类和存储;在基于复用的软件开发中,可复用构件的检索,提取和组装;可复用构件的度量等等.
4 基于复用的软件开发过程
软件过程又称软件生存周期过程,是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合.一个良好定义的软件过程对软件开发的质量和效率有着重要影响.当前,软件过程研究以及企业的软件过程改善已成为软件工程界的热点,并已出现了一些实用的过程模型标准,如CMM,ISO9001/TickIT等.
然而,基于构件复用的软件开发过程和传统的一切从头开始的软件开发过程有着实质性的不同,探讨适应于软件复用的软件过程自然就成为一个迫切的问题.
Caldieri和Basili提出了一种工厂化的软件生产方式 [Caldiera 91].在这种模型中,构件生产组和系统开发组间严格按照生产者?消费者关系进行任务分工,经验工厂负责生产,提供构件,项目组不再编程,而是通过从经验工厂中请求所需的构件集成组装而得到最终所需的系统.经验工厂的活动分为同步活动和异步活动.同步活动指配合项目组的活动,接收构件查找请求或定制请求,为项目组服务.异步活动指有目的的构件生产或对同步活动中的构件进行再工程以提高构件的可复用性.
4.1 产品线系统
产品线系统(Product Line System)是CMU/SEI提出的产品开发的组织方式.产品线集中体现了软件复用思想.经验表明,单靠技术方法并不能保证成功的产品线生产能力,经济,组织,管理和过程在建立和维护产品线中起到了关键作用.一个产品线是共享一组共同设计及标准的产品族,从市场角度看是在某市场片断中的一组相似的产品.建立产品线是根据生产的经济学,使产品族可复用构件能达到最大限度的复用目的.产品线方法可以通过各种可复用软件构件,如需求,需求规约,构架,代码构件,文档,测试策略和计划,测试案例和数据,开发人员的知识和技能,过程,方法及工具等,支持最大限度的软件复用.产品线也是基于在相同产品价格条件下提高竞争力的商业考虑.
产品线系统已有成功的应用实例.典型的是美国空军电子系统中心(ESC)和瑞典CelsiusTech System公司的产品线系统.
在ESC采用的产品线方法[Brownsword 96]中,主要有五个关键性的组织,即外围的用户,SPO(系统项目办公室),和产品线内部的系统构架组,产品线工程中心和产品线构件支持组.SPO是直接和用户打交道的组织,由它来决定是开发一个新系统还是从已有的系统升级.SPO和用户都是产品的客户,它们介入了整个开发阶段,在系统从原型演化到最终部署的过程中进行监控和认证.产品线内部的三个关键性组织分别是系统构架组(SAG),产品线工程中心(PLEC),产品线构件支持组(PLAS).
CelsiusTech系统公司是瑞典主要的命令与控制系统供应商.1985年12月,该公司同时接到了两份合同-瑞典海军和丹麦海军的轮船系统,两个系统都需要很强的容错性和分散性,比以往开发的系统要复杂得多.在面临两个结构类似的大型系统的并行开发情况下,以前开发单个系统的方法需要大量的投资和人力,因此公司的管理者和高级技术人员决定采用一种新的产品族系列的开发方法,这就是SS2000产品线 [Cohen 96].采用SS2000产品线方法后,CelsiusTech公司获得了巨大的成功,将硬件与软件的费用比例从过去的35:65变成了80:20.由于软件的费用得到了良好的控制,该公司现已把精力投入到了降低硬件费用上.
这两个产品线系统的共同特点是构架组,构件组和集成组的分离.构架组负责产品线系统构架的定义和演化.构件组负责根据产品线系统构架,生产和管理可复用构件.集成组则根据具体客户的需求,利用产品线系统构架和可复用构件进行具体的系统集成.
使用产品线方法的好处是显而易见的,它将以更小的代价和资源,更快地开发出系统.由于使用的是高度可靠,性能经过验证的可复用构件,产品线系统的质量将大大提高.而且产品线方法还开拓了一个广阔的构件市场,这将极大地促进软件构件业的发展.
但是,产品线方法仍然面临着很大的挑战和障碍,这主要体现在:
文化上-产品线策略意味着软件组织和管理者对他们产品开发的直接控制减少了,对其它组织的依赖增加了,这意味着一种思想观念上的转变.
战略计划上-产品线的规划不仅是对一组相关系统的管理过程,还需要考虑用户的长期需要和现有产品线的能力,对未来的发展作出长远规划.
需要折衷-产品线方法需要用户作出折衷,是”独自开发一个恰好是我所需要的系统”,还是”利用产品线开发一个与我的需要非常接近的系统,但可以节省开发的代价和时间”.
资源的所有权-产品线构件归谁”所有” 在目前的体制下,这的确是一个容易引起纠纷的问题.这就需要整个软件开发和管理组织的重心从当前的程序获取转移到商业化的构件开发上来.
提拔和奖励-当前的开发方法主要是提拔和奖励那些提交了最终系统的开发人员,采用产品线方法后还应该提拔和奖励那些开发构件和促进了产品线开发中构件复用的人员.
4.2 复用成熟度模型(RMM)
受SEI的能力成熟度模型(Capability Maturity Model,缩写为CMM)的启发,已出现了几个复用成熟度模型(Reuse Maturity Model,缩写为RMM),作为对企业内复用水平层次的度量.
在IBM的RMM中,将企业的软件复用水平分为五级.随着复用成熟度级别的提高,复用的范围,复用使用的工具和复用的对象都有变化
:①初始级(Initial):不协调的复用努力.复用是个人的行为,没有库的支持,主要的复用对象是子程序和宏;②监控级(Monitored):管理上知道复用,但不作为重点.复用是小组的行为,有非正式的,无监控的数据库,复用的对象包括模块和包;③协调级(Coordinated):鼓励复用,但没有投资.复用的范围包括整个部门,有配置管理和构件文档的数据库,复用的对象包括子系统,模式和
框架
;④计划级(Planned):存在组织上的复用支持.在项目级别支持复用,有复用库,复用的对象包括应用生成器;⑤固有级(Ingrained):规范化的复用支持.复用成为整个企业范围的行为,有一组领域相关的复用库,复用的对象包括DSSA.
Loral Federal System公司的RMM也分为五级
:①初始级:偶尔的开发过程复用;②基本级:在项目级上定义的开发过程复用;③系统化级:标准的开发过程复用;④面向领域级:大规模的子系统复用;⑤软件制造级:可配置的生成器及DSSA.
HP的RMM将复用成熟度与复用率联系起来,也分为五级
:①无复用:-20%至20%的复用率;②挖掘整理:15%至50%的复用率;③计划复用:30%至40%的复用率;④系统化复用:50%至70%的复用率;⑤面向领域的复用:80%至90%的复用率.
5 结束语
自软件复用被提出以来,人们进行了许多复用的实践活动.归纳起来,复用项目的成功主要发生于以下几种情形
:①在较小的特定领域;②在理解充分的领域;③当领域知识变动缓慢时;④当存在构件互联标准时;⑤当市场规模形成时(大量的项目可以分担费用);⑥当技术规模形成时(有大量可用的,可获利的构件).
而复用项目失败的原因主要包括
:①缺乏对复用的管理支持;②没有对开发可复用软件及复用已有软件的激励措施;③没有强调复用问题的规程或过程;④没有足够的可复用资源;⑤没有良好的分类模式,使得构件查找比较困难;⑥没有良好的构件库支持和控制复用;⑦构件库中的构件没有良好的接口;⑧已有的部件不是为了复用而开发的.
经过软件复用的研究和实践方面的努力,在构件开发方面已经取得一定的成果.当前已存在一些政府,军方或企业自己拥有的构件库,在某些领域,如科学计算,已有商用的构件存在.同时,存在大量独立于应用领域的计算机特定的软件构件,如:程序设计语言的类库,函数库,VBX,OCX,用户界面构件等.但对大多数特定领域来说,可复用构件仍十分短缺,从而形成了一个巨大的应用软件构件市场.
软件复用技术将促进软件产业的变革,使软件产业真正走上工程化,工业化的发展轨道
.软件复用将造成软件产业的合理分工,专业化的构件生产将成为独立的产业而存在,软件系统的开发将由软件系统集成商通过购买商用构件,集成组装而成.软件复用所带来的产业变革将会带来更多的商业契机,形成新的增长点.
在当前的情况下,我国的软件产业发展一定要结合国情,抓住机遇.软件
构件技术的应用
,正在促进软件产业改革和重组分工,这对我国软件产业的发展是一个良好的机遇.我国正在大力加强国家信息化工作,具有广大的信息市场.由于具体的国情,大多数信息系统的开发工作是由国内公司承担,因此,也就培养了一大批领域专家,为推行软件构件技术,发展软件构件生产业奠定了良好的基础.同时,在构件技术方面,多年的攻关研究已使我们具有良好的技术积累.我们应在国家支持下,在行业部门的领导下,以政府或行业行为的方式推广软件构件技术,促进软件构件企业的发展.我国已失去了较多的信息产品市场,目前,正面临振兴的机遇,如何抓住机遇,也是严峻的挑战.
在软件产业的发展策略上,应由政府或行业主管部门组织构件标准规范的制定和发布;选择若干领域进行软件构件技术的推广和软件构件企业建设的试点工作,推行基于构件-构架模式的软件生产线的工程化,工业化软件生产技术;加快软件复用和软件构件技术的普及,培训工作,培养一批高质量的领域分析员队伍;制定合理措施及政策,激励软件构件技术的采用和推广;建立软件风险投资机制和软件生产基金,激励构件专门企业的形成和零散构件的开发;尽快完成试点工作,及早进军国际应用构件市场.
参考文献
[Brownsword 96] Lisa Brownsword, Paul Clements, “A Case Study in Successful Product Line Development”, Technical Report, CMU/SEI-96-TR-016, October 1996
[Caldiera 91] Caldiera, V. R. Basili, “Identifying and Qualifying Reusable Software Components”, IEEE Computer, vol.24, no. 2, pp. 61-70, Feb. 1991
[Cohen 92] Sholom G. Cohen, Jay L. Stanley, Jr., A. Spencer Peterson, Robert W. Krut, Jr., “Application of Feature-Oriented Domain Analysis to the Army Movement Control Domain”, Technical Report, CMU/SEI-91-TR-28, ESD-91-TR-28, June 1992
[Cohen 96] Sholom Cohen, Seymour Friedman, Lorraine Martin, Tom Royer, Nancy Solderitsch, Robert Webster, “Concept of Operations for the ESC Product Line Approach”, Technical Report, CMU/SEI-96-TR-018, September 1996
[Feiler 93] Peter H. Feiler, “Reengineering: An engineering problem,” Technical Report CMU/SEI-93-SR-5, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 1993
[Foreman 97] John Foreman, Kimberly Brune, Patricia McMillan, Robert Rosenstein, “Software Technology Review”, CMU/SEI, June 1997
[Garlan 93] David Garlan, Mary Shaw, “An Introduction to Software Architecture”, Advances in Software Engineering and Knowledge Engineering, volume I, World Scientific Publishing, 1993
[Microsoft 95] Microsoft Corporation, “The Component Object Model Specification”, Version 0.9, October 24, 1995 [online]. Available WWW (1995)
[Microsoft 96] Microsoft Corporation, “Distributed Component Object Model Protocol COM/1.0”, draft, November 1996 [online]. Available WWW (1996)
[Mili 95] Hafedh Mili, Fatma Mili, and Ali Mili, “Reusing Software: Issues and Research Directions”, IEEE Transactions on Software Engineering, Vol. 21, No. 6, pp. 528-562, June 1995
[NATO 91a] NATO, “NATO Standard for Developing Reusable Software Components”, Vol. 1 of 3 volumes, NATO contact number CO-5957-ADA, 1991
[NATO 91b] NATO, “NATO Standard for Management of a Reusable Software Component Library”, Vol. 2 of 3 volumes, NATO contact number CO-5957-ADA, 1991
[NATO 91c] NATO, “NATO Standard for Software Reuse Procedures”, Vol. 3 of 3 volumes, NATO contact number CO-5957-ADA, 1991
[OMG 96] Object Management Group home page [online]. Available WWW (1996)
[Petro 95] James Petro, Michael E. Fotta, David B. Weisman, “Model-Base Reuse Repository – Concepts and Experience”, Proc. Seventh International Workshop on CASE, July 10-14, 1995, Toronto, Ontario, Canada, Edited by Hausi A. Muller & Ronald J. Norman, pp. 60-69, IEEE Computer Society Press, Los Alamitos, California, USA
[Prieto-Diaz 93] Ruben Prieto-Diaz, “Status Report: Software Reusability”, IEEE Software, Vol. 10, No. 3, May 1993, pp. 61-66
[RIG 93] RIG, “Basic Interoperability Data Model (BIDM)”, RPS-0001, Reuse Library Interoperability Group, April, 1993
[RIG 94] RIG, “Uniform Data Model for Reuse Libraries (UDM)”, RPS-0002, Reuse Library Interoperability Group, January, 1994
[STARS 92] STARS, “Asset Library Open Architecture Framework Version 1.2” Informal Technical Report STARS-TC-04041/001/02, 1992/8
[Tracz 95] Will Tracz, “Confessions of a Used Program Salesman – Institutionalizing Software Reuse”, Addison-Wesley Publishing Co., New York, NY, April 1995
– 作者: nike_liu 2005年12月2日, 星期五 14:09