可复用软件（共7篇）
可复用软件 篇1
摘要：研究了软件测试用例可复用性的度量方法,提出了测试用例可复用性度量模型TCRM。该模型将易理解性、独立性、适用性、可配置性作为影响可复用性的4个子特性,并使用可信度作为修正特性。提出了针对TCRM模型的度量方法,TCRM模型及其度量方法可给构建软件测试用例库和评价软件测试用例的人员提供参考。
关键词：软件测试用例,可复用性,度量
0 引 言
软件测试是软件工程不可或缺的一个环节,是软件产品质量的重要保证。当今软件行业快速的开发过程使得软件测试面临不少困难,如测试需求不断增加,新加入的测试人员测试技能和经验不足等。采用软件测试复用是解决测试人员经验不足、提高测试的质量、解决软件测试效率的有效途径。软件测试中的复用主要包括测试过程的复用、测试方法的复用和测试技巧的复用,测试技巧的复用主要指测试用例的复用。将大量的测试用例收集到测试用例库中供测试人员使用,以实现测试用例的复用。对测试用例的可复用性进行度量是保证测试用例库中测试用例的可复用性的关键技术之一。此外,对测试用例的可复用性进行度量还能帮助测试用例库的管理员对用例库进行有效管理和为测试人员选用可复用用例时提供参考。
基于以上目的,本文开展了对软件测试用例可复用性度量的研究。
1 软件可复用性度量相关研究
NATO制定的软件复用指导性标准将可复用性定义为软件构件可以被复用的程度或范围[1]。其中的软件构件不仅包括源代码构件、还包括测试用例、需求规约、软件构架等软件过程中可复用的部分。
国外许多质量模型都提到了软件构件的可复用性,如NATO模型[2]、REBOOT模型[3]等。Jeffery S.Poulin在对众多可复用性度量方法进行了总结后,将软件可复用性度量方法分为两类:先验方法和定性方法。先验方法是根据客观的实验数据进行度量的方法;定性方法则是根据主观认同的规范和标准进行度量的方法[4]。
ISO/IEC9126:2001是业界广泛认可的质量标准,它从外部质量、内部质量和是使用质量三个层面刻画了软件质量,在内、外部质量模型中提出了功能性、可靠性、易用性、效率、维护性、可移植性等质量特性,使用质量模型中提出了有效性、生产率、安全性、满意度等质量特性[5,6,7,8]。
2 测试用例的可复用性度量
测试用例是为一个特定目标所开发的测试实现及其环境、测试输入、测试条件及预期结果的集合,是一种特殊的软件构件。测试用例相对于其他软件构件有其自身的特点,实现对其可复用性的度量需要从设计原则、描述模式等方面考虑。
2.1 可复用测试用例设计原则
本文以上海市计算机软件评测重点实验室承担的国家“863”课题为背景和所开展的软件评测项目为对象,研究得出以下的可复用测试用例设计原则:
(1) 可复用的测试用例应易于理解。
(2) 可复用的测试用例应是独立的。
(3) 可复用的测试用例应具有较好的适用性。
(4) 可复用的测试用例应易于修改、配置。
其中,原则(1)要求测试用例的描述信息完整、规范和易于理解;原则(2)要求测试用例具有强内聚性,能不依赖其他测试用例和特定的测试环境独立运行;原则(3)要求测试用例尽可能适用于较多的领域或平台;原则(4)要求测试用例具有方便修改例化和重新配置的能力,进而能在新的运行环境中工作。
2.2 可复用性度量模型TCRM
借鉴ISO/IEC9126:2001外部质量模型和使用质量模型的基础上,本文提出测试用例可复用性度量模型TCRM(Test Case Reusability Metrics),如图1所示。TCRM模型以可复用测试用例的设计原则为依据,选取易理解性U(Understandability)、独立性I(Independence)、适用性A(Adaptability)、可配置性C(Configurability)(UIAC特性)4个对可复用性有重大影响的特性作为其子特性。此外,TCRM模型还将测试用例使用质量中的可信度作为可复用性的修正特性。因为,复用者对测试用例的信任情况在一定程度上反映了该测试用例本身的可复用能力。使用可信度对可复用性的度量值进行修正,可以使测试用例可复用性的度量值更加接近实际值。使用TCRM模型后,对测试用例可复用性的度量可以转化为对UIAC特性和可信度的度量。
以下是TCRM中UIAC特性以及可信度的具体说明:
(1) 易理解性 它指测试用例使复用者能理解该用例是否合适以及如何将该用例应用于当前测试目标和测试场景的能力。复用者要复用某个测试用例,首先需要理解该测试用例,对测试用例的理解包括对测试目的、测试场景、测试要点的理解。只有对该用例充分理解后才能判断其是否能达到复用要求。所以,测试用例的易理解性直接影响了复用者对测试用例的选择,是可复用性的重要特性。
(2) 独立性 它指测试用例在运行时不依赖于其他的测试用例和特定测试环境而能独立工作的程度。通常情况下,测试用例之间存在相互联系,一些测试用例的运行环境取决于前一个测试用例的执行状态,当前一个用例因为测试环境的变化而失效时,后一个测试用例也随之失去了复用价值。因此,要实现复用,测试用例应该具有相对独立性,即测试用例之间不应该存在线性依赖。能够不依赖特定测试环境的测试用例也更容易被复用。
(3) 适用性 它指测试用例应用的普适性,包括测试场景、被测软件类型的种类,被测软件领域的广度等。测试用例的适用程度越高越容易被复用。
(4) 可配置性 它指测试用例具有被修改例化、配置的能力。测试用例通常是针对特定的测试环境设计的,需要在一定的环境中才能被执行。复用者进行复用时,目标环境与被复用测试用例所需环境可能存在差异,这时往往需要对测试用例进行修改才能实现复用。测试用例被修改和配置的难易程度也是决定其可复用性的关键因素。
(5) 可信度 它指复用者对测试用例的信任程度。可信度是测试用例使用质量的一部分,从复用者的角度出发,用例复用次数、复用者评分、复用者评论等因素都反映了复用者对测试用例的信任程度。
3 TCRM模型的实现
本文设计了一套针对TCRM模型的度量方法,该方法第一步先对可复用的软件测试用例进行统一描述,即设计一个可复用测试用例模式,所有要进行度量的测试用例使用该模式描述。可复用测试用例模式必须能够满足实际软件测试需要,并且其中的元素或子元素能方便进行统计。第二步找出可复用测试用例模式中的元素或子元素和UIAC特性以及可信度之间的关联。第三步使用对某个特性有影响的元素进行计算,得到测试用例该特性的度量值。
3.1 可复用测试用例模式
本文设计的可复用测试用例模式包括7个元素,即用例ID,前驱用例ID,版本信息,接口信息,使用信息,测试概要和测试项,如表1所示。其中接口信息可以使测试用例满足检索要求,同时也使测试用例的描述更加全面;使用信息用来记录复用者使用该测试用例时的信息;而测试项可以为任意多项,每个测试项也可以有任意多步骤。表1列出了可复用测试用例模式包括的元素和子元素,以及它们的说明,同时也给出了各个元素所影响的特性。
3.2 度量方法
测试用例使用可复用测试用例模式进行描述后,即可开始对测试用例的可复用性进行度量。可根据表1中影响UIAC特性的元素对UIAC特性进行度量,从而得到测试用例可复用性的初始值,然后再对可信度进行度量,最后使用可信度的度量值对可复用性的初始值进行修正。
(1) UIAC特性度量
1) 易理解性度量
易理解性主要根据测试概要和测试项进行度量,详细度量如下:
易理解性:U=XUTs+YUTi(0≤U≤1,越接近1易理解性越好)。
度量方法:
UTs为测试概要的度量值,UTs=WTpUTp+WTcUTc+WTeUTe(WTp,WTc,WTe为权值,表示UTp、UTc、UTe影响UTs的程度,且满足归一化WTp+WTc+WTe=1,0≤UTs≤1),若度量的测试用例没有测试目的、测试场景、测试要点的描述则UTp、UTc、UTe对应为0,反之为1。
UTi为测试项的度量值,UTi=N/Ti,Ti为度量的测试用例包括的测试项数目,该公式中N为度量的测试用例前置条件,测试操作、测试输入和预期结果的描述全部存在的测试项数目。
X、Y为变量,分别表示UTs、UTi影响U的程度,满足X+Y=1。设置X、Y两个变量是因为随着测试项数目的增加,理解测试项所花费的成本也相应增加,即测试项对测试用例易理解性的影响将增大,用Y的增减来表示UTi对U影响程度的增减。这里取Y=WY1+WY2((Ti-1)/Ti),WY1、WY2为权值,用于控制Y的取值,进而控制UTs、UTi对U的影响程度,且满足WY1+WY2=1。从Y的计算公式中,我们可以看到当测试项增加到一定的值时Y将趋于1,X趋于0,这和实际情况不相符合,因为实际当中对测试概要的理解始终影响着对整个测试用例的理解。所以,Ti>10时,取Ti=10来对Y进行计算。
2) 独立性度量
独立性主要根据前驱用例ID和测试场景进行度量,详细度量如下:
独立性:I=WPtIPt+WTcITc(WPt、WTc为权值,表示IPt、ITc影响I的程度,且WPt+WTc=1,0≤I≤1,越接近1独立性越强)。
度量方法:
IPt为前驱用例的度量值,该度量的测试用例存在前驱用例则IPt为0,反之为1。
ITc为测试场景的度量值,度量测试用例的测试场景如果包含特定的测试环境,如特定的操作系统,则ITc为0,反之为1。
3) 适用性度量
适用性度量主要根据接口信息进行度量,详细度量如下:
适用性:A=WDtADt+WTtATt+WStASt+WSdASd(WDt、WTt、WSt、WSd为权值,表示ADt、ATt、ASt、ASd影响A的程度,WDt+WTt+WSt+WSd=1,0≤A≤1,越接近1适用性越强)
度量方法:
ADt是设计技术的度量值,其值为度量的测试用例用到的设计技术与所有列出的设计技术的比值。
ATt是测试类型的度量值,当度量的测试用例测试类型为功能测试时,ATt等于1;为其他测试类型,ATt等于0.5,无明确测试类型时,ATt为0。
ASt是被测软件类型的度量值,其值为度量的测试用例所测试的软件类型数与所有列出的被测软件类型数的比值。当被测软件类型为“通用”时,ASt值为1。
ASd是被测软件领域的度量值,其值为度量的测试用例所测试的软件应用领域数与所有列出的被测软件领域数的比值。当被测软件领域为“通用”时,ASd值为1。
4) 可配置性度量
可配置性度量主要根据测试项进行度量,详细度量如下:
可配置性:C=WPCP+WSCS(WP、WS为权值,表示CP、CS影响C的程度,WP+CS=1,0≤C≤1,越接近1可配置性越高)。
度量方法:
CP是测试项中前置条件的度量值,CP=1-N/Ti,Ti为度量的测试用例包括的测试项数目,该公式中N为度量的测试用例中以其他测试项执行结果作为前置条件的测试项数目。
CS是测试项中测试步骤的度量值,CS=N/S,S为度量的测试用例包括的测试步骤数目,该公式中N为度量的测试用例中能独立于前后测试步骤的测试步骤数目,即能单独执行的测试步骤。
(2) 可复用性初始值
可复用性初始值主要由UIAC特性决定,度量如下:
可复用性:R=WUU+WII+WAA+WCC(WU、WI、 WA、WC为权值,表示U、I、A、C影响R的程度,WU+WI+WA+WC=1,0≤R≤1,越接近1可复用性越高)。
为了获得以上度量方法中权值的取值,我们从大量实际应用的测试用例中挑选出100个,100个中有被复用过多次的测试用例,有较少被复用的测试用例,也有不具备复用价值的测试用例。对这100个测试用例进行处理后交由10个具备丰富项目经验的资深测试工程师进行评分。测试工程师分别对100个测试用例的易理解性、独立性、适用性、可配置性和可复用性进行评分,评分从0分到1分,分值越高特性越强。
要获得易理解性度量方法中权值的取值,先对100个测试用例的测试概要和测试项进行随机处理,先随机的去除一些测试用例的测试目的、测试场景、测试要点的描述,再随机去除一些测试用例某个测试项的测试输入或测试数据,但测试用例的其他元素全部予以保留。将进行处理后的测试用例交由10位测试工程师,让他们针对易理解性进行评分,再统计每个测试用例的易理解性平均得分。对100个测试用例的易理解性得分进行统计计算后可以得到WTp、WTc、WTe、WY1、WY2的值。
采取上述方法同样可得到其他特性度量方法中的权值,最终得到度量公式为:
U=XUTs+YUTi
其中: Y=0.37+0.63((Ti-1)/Ti)
X=1-Y,UTs=0.35UTp+0.42UTc+0.23UTe
I=0.75IPt+0.25ITc
A=0.18ADt+0.45ATt+0.25ASt+0.12ASd
C=0.65CP+0.35CS
R=0.32U+0.23I+0.28A+0.17C
(3) 可复用性修正
可信度度量主要根据使用信息进行度量,详细度量如下:
可信度:Cr=WRcCrRc+WRmCrRm(WRc、WRm为权值,表示CrRc、CrRm影响Cr的程度,WRc+WRm=1,-1≤Cr≤1,Cr的绝对值越大则修正幅度越大)。
度量方法:
CrRc为测试用例复用次数的度量值,CrRc=(Rc-QRcDc)/max(Rc,QRcDc),-1≤CrRc≤1,Rc为度量的测试用例的复用次数,Dc为度量的测试用例加入到测试用例库的天数。QRc为系数,取值范围为正实数,它用来表示Rc和Dc的关系,其值将根据测试用例库的实际情况设置。
CrRm为测试用例复用者评分的度量值,其值为所有复用者评分的平均值Rm与R的差值,复用者评分的范围为0分至1分,则0≤Rm≤1,-1≤CrRm≤1。
修正后的可复用性度量如下:
当Dc≤30,R=0.32U+0.23I+0.28A+0.17C
当Dc>30
R=0.32U+0.23I+0.28A+0.17C+WCrCr(WCr为权值,表示Cr影响R的程度,0≤WCr≤1)
上述公式的计算结果R>1时,取R=1,R<0时,取R=0。
3.3 应用实例
本节以实际项目中常见的系统登录为例,来说明如何根据上节提出的度量方法对测试用例的可复用性进行度量。
表2为验证系统登录的测试用例实例,以下是对该测试用例可复用性度量值的具体计算方法。
计算易理解性U:
UTs=0.35×1+0.42×1+0.23×1,UTi=2/2=1
Y=0.37+0.63((2-1)/2)=0.685
U=(1-0.685)×1+0.685×1=1
计算独立性I:
IPt=1,ITc=1
I=0.75×1+0.25×1=1
计算适用性A:
ADt=1/18(18种设计技术) ATt=1 ASt=1 ASd=1
A=0.18×1/18+0.45×1+0.25×1+0.12×1=0.83
计算可配置性C:
CP=1-0/2=1 CS=2/2=1
C=0.65×1+0.35×1=1
则可复用性的初始值为:
R=0.32×1+0.23×1+0.28×0.83+0.17×1=0.9524
为了说明可信度的计算方法和可复用性的修正过程,这里暂取Rc、Dc为100、40,Rm取0.9,WRc、WRm取0.75、0.25,QRc取5,WCr取0.15。
则可计算可信度Cr:
CrRc=(100-5×40)/(5×40)=-0.5
CrRm=0.9-0.9524=-0.0524
Cr=0.75(-0.5)+0.25(-0.0524)=-0.3881
最后,对可复用性的初始值进行修正:
R=0.9524+0.15(-0.3881)=0.89415
3.4 度量方法验证
使用TCRM模型对前文提到的100个测试用例进行度量,其度量结果与这些测试用例的被复用次数Rc进行对比。
根据Rc的取值划分10个区间,用区间中间点的值作为该区间的区间值,区间值越高表示该区间内测试用例被复用次数越多,即该区间内测试用例的可复用性越高。若一个测试用例的Rc介于一个区间,则该测试用例属于该区间,以此统计每个区间的测试用例数量。然后使用TCRM模型对区间内测试用例的可复用性进行度量,得到区间内每个测试用例的可复用性度量值,计算它们的平均值A(R)。最后对比每个区间的区间值与A(R),具体对比情况可见图2。
从图2可以看到,A(R)与每个区间的区间值基本成正比,即A(R)的大小变化与测试用例被复用的次数的变化基本是一致的。该结果表明使用TCRM模型对测试用例的可复用性进行度量所得到的度量值,基本能代表测试用例实际所具有的复用能力。
4 TCRM模型应用
TCRM模型将应用于国家“863”项目——基于可复用测试用例库的测试管理平台(以下简称测试管理平台),该项目使用TCRM模型来对测试用例库中的测试用例进行度量。
测试管理平台以可复用测试用例库RTCL(Reusable Test Case Library)为核心,为软件企业提供完成整个软件测试流程的所有功能,其组织和使用方式可见图3。测试管理平台中的测试用例将使用可复用测试用例模式进行描述,从而更好地实现测试用例的搜索、复用和度量。使用测试管理平台,当用户需要设计新的测试用例时,只需输入搜索条件即可在RTCL中搜索所需的测试用例,用户对搜索到的测试用例可直接复用,亦可修改后复用。用户新建的测试用例经过验证后将收集到RTCL中,这一机制不仅使RTCL中的测试用例不断增加,也实现了不同用户之间测试用例的共享。测试管理平台通过用例度量系统对RTCL中的测试用例进行度量和管理。用例度量系统使用TCRM模型对RTCL中测试用例的可复用性进行度量,度量后将删除不具有复用特性和冗余的测试用例,使其进入历史用例库,这不但能保证RTCL中测试用例的高可复用性,还能提高RTCL的用例检索效率。测试管理平台也支持管理员手动修改和更新RTCL和历史用例库中的测试用例。
在测试管理平台的使用过程中,管理员可根据实际使用情况设置和调整可信度度量的权值WRc、WRm、系数QRc以及可复用性度量的权值WCr,即调整可信度对可复用性的修正幅度。
5 结束语
本文提出了测试用例可复用性度量模型TCRM,以及针对TCRM的度量方法,实现了对测试用例可复用性的度量。在实际应用TCRM模型和度量方法时,使用者可根据当前系统的实际情况,对上述度量公式中的权值和系数进行调整。测试用例可复用性度量的实现有助于可复用测试用例库构建和控制以及最终的测试用例复用。
参考文献
[1]郭立峰,郭耀,常继传.NATO软件复用标准导论[J].计算机科学,1999,26(5).
[2]NATO.NATO Standard for Management of a Reusable Software Compo-nent Library[S].NATO Contact Number CO-5957-ADA,1991.
[3]Sindre G,Conradi R,EAKarlsson.The REBOOTApproach to SoftwareReuse[J].Journal of Systems and Software,1995.
[4]Jeffery S,Poulin.Measuring software reusability[C]//Proceedings ofthe Third International Conference on Software Reuse:Advances inSoftware Reusability.Los Alamitos.CA:IEEE Computer Society Press,1994.
[5]GB/T16260.1-2006(ISO/IEC 9126)第1部分:质量模型[S].软件工程-产品质量,2006.
[6]GB/T16260.2-2006(ISO/IEC 9126)第2部分:外部度量[S].软件工程-产品质量,2006.
[7]GB/T16260.3-2006(ISO/IEC 9126)第3部分:内部度量[S].软件工程-产品质量,2006.
[8]GB/T16260.4-2006(ISO/IEC 9126)第4部分:使用质量的度量[S].软件工程-产品质量,2006.
可复用软件 篇2
关键词：可复用软件,构件,开发技术
随着社会各领域对软件开发的需求日益增长, 可复用软件受到了社会各界的高度关注, 从软件应用和系统构造等多方面入手, 分析研究可复用软件的具体开发技术, 能够很大程度地提升可复用软件的开发质量, 改善软件应用性能。
1 可复用软件的开发过程
1.1 可复用软件的模型开发
操作团队要将模型开发工作作为提升可复用软件运行质量的基础工作。首先, 要秉承正确的软件开发思路, 对可复用软件的具体构建情况进行研究, 实现可复用软件开发活动同工业生产活动的对接。深入分析研究用户信息, 以便操作团队能够根据软件开发活动的具体要求, 利用软件构件库的资源进行功能软件的设计和开发。在软件的应用系统组建完成之后, 要根据相关构件的数量进行模型开发工作, 确保模型开发团队拥有足够数量的可复用构件[1]。使用自行研发的方式设计新型构件, 使生命周期模型同软件过程模型可以实现良好的对接。要根据已完成开发的软件应用需要, 对后续活动进行高质量的规划, 使软件应用能够和控制模型一同成为构件开发质量提高的重要因素。尝试开发并应用多种类型的软件模型, 这样既可以使用瀑布模型进行软件基础性资源的应用, 也可以利用喷泉模型进行软件应用质量的提升, 但要保证各类模型能够共同提升软件的应用性能, 并根据编码和后续测试活动的要求, 对测试活动进行控制, 使其能够切实保证生命周期模型的质量。
1.2 可复用软件的构件开发
首先对构件的开发技术进行分析研究, 使各项技术能够有针对性的被特定的开发产品使用。可以尝试使用多种开发技术并行的方式进行产品的开发研究, 以便软件可以更好地根据生命模型的状况进行开发过程的研究。使用打包的形式对各式各样的软件开发程序进行调查, 使软件的开发活动能够更好地根据可复用构件的状况进行完善。可以使用独立的方式进行相关软件的分析研究, 以便软件的分析工作能够与不同领域的研究工程共同推进[2]。还可以使用多种软件共同研发的方式进行对软件应用性能的比较, 使各类软件同开发目标相结合, 如果已经开发的系统能够实现开发领域性能的提高, 则可以根据不同软件之间的特点, 对各种软件开发技术进行调查, 使软件能够更好地利用抽象编码进行可复用构件的研发。根据软件的具体应用领域情况, 对软件的领域分析活动进行分析, 使软件能够在具备特性的前提下提升应用质量, 如果软件能够通过文件存储的方式实现文档的构建, 则需要根据公共特性的情况进行相关编码的抽取, 使编码可以更好地进行应用质量的提升[3]。开发主体要将软件的开发期限提前, 使软件能够利用开发阶段构件的合理使用实现软件构件开发周期的缩短和软件质量的提升。
1.3 可复用软件的领域分析
将不同领域的研究工作进行结合, 使可复用软件的构建团队能够选择使用正确的软件开发技术。根据软件的开发需要, 对不同应用领域的模型进行研究, 使研究团队能够根据其获得可复用软件应用领域的共性或通用部分, 使应用领域可以更具开放性。正确使用各类知识进行应用领域的特点分析, 使不同种类的软件资源能够实现应用质量的提升[4]。根据集成应用系统的运行要求, 对构件的装配状态进行研究, 使构件能够更好地通过定义形式进行应用模型的开发。利用互换的形式进行构件资源应用质量的提升, 以便应用系统之间可以通过装配状况的转变实现高度通用性。
2 可复用软件的构件设计
2.1 设计环节操作方法
在设计阶段对可复用软件的运行要求进行研究, 通过不同组织框架也能实现不同组织的良好配合, 使各个构件之间能够具备更好的可复用性, 从而使构件可以更加独立地完成质量提升目标。保证相同构件之间能够进行良好的互换, 使软件的功能可以得到更好的实现。利用软件评选的方式进行各类软件开发质量的控制, 使软件设计环节能够拥有更多的各类软件相比较产生的历史数据作为参考。在软件开发的过程中, 要确保可复用构件的数量能够保证设计环节的正常推进, 还要确保构件是通过正规渠道采购的。拓展相关构件的获取渠道, 使构件可以在合作伙伴方面获得支持。在进行渠道拓展的过程中, 操作团队还要加强对测试技术的重视, 使设计环节能够从测试技术领域获得软件质量的判断方法, 并提升构件的质量等级[5]。
2.2 测试环节构建机制
根据不同应用领域的实际需要, 对构件的通讯机制进行制定, 使构件可以根据相同的标准进行数据信息资源的共享和处理。如果构件不能保证对系统相关数据进行良好的处理, 则要进行软件开发机制的调整, 使构件能够更好地以零件的形式为系统提供运行支持, 并保证对开发的软件提供必要的应用服务[6]。进行测试代码的设置, 使后续的测试工作能够在规范的方式下进行, 在相关代码完成测试以后, 要细化测试程序, 使可复用软件的每一个开发功能都能够通过测试用例完成测试。根据不同构件的可复用特点, 对构件质量进行研究分析, 以更好地提升构件的应用质量。从系统整体需求的角度出发, 对系统的测试环节进行设计, 使系统可以保证实际提供的功能能够同实际需求一致。
2.3 测试环节操作方法
将各种类的信息技术进行综合分析, 使选用的技术能够提高软件资源开发质量, 如果构件能够保证对新型软件的技术支持, 则要加强对软件获取渠道的重视, 提升测试环节的规范性[7]。使用规范的方式对软件资源的开发质量进行研究, 使操作团队能够将已经掌握的信息资源进行量化, 提升对软件开发质量判断的准确性。
3 结语
可复用软件的开发是软件复用思想的最好体现, 可复用软件使用可复用构件来组装开发新的应用系统, 本文在分析可复用软件应用的基础上, 对可复用软件的具体开发过程进行了深入研究, 并对相关软件的具体构建情况进行了认真的调查分析。可复用软件的应用可以极大地降低软件重复设计带来的资源浪费, 同时也能够解决不同软件之间的差异性带来的不兼容问题, 让同行业、同领域的相似软件逐渐走向规范化、标准化。
参考文献
[1]刘舒宁.支持复用的软构件管理技术与系统研究[D].杭州:浙江大学, 2015.
[2]王周文, 仇卫文, 李波.浅析基于安全可靠软硬件的统计领域业务软件开发模式[J].计算机光盘软件与应用, 2015 (16) :35-36.
[3]程林钢.软构件可复用性的计算模型研究[J].现代计算机 (专业版) , 2013 (32) :15-18.
[4]刘舒宁.支持复用的软构件管理技术与系统研究[D].杭州:浙江大学, 2015.
[5]唐成.软构件的本体描述及组装智能化方法的研究[D].上海:东华大学, 2013.
[6]王艳红.一种改进的网构软件服务质量评估方法[D].武汉:华中师范大学, 2015.
可复用测试用例研究 篇3
随着软件测试的长期实施, 一般都会积累丰富的高质量的测试用例, 如果能够在以后的软件测试工作中利用现有的资源, 那么会减少测试用例设计的时间, 提高软件测试过程中发现软件缺陷的效率, 缩短软件测试的时间及成本, 保证软件产品的质量, 给软件产品的按时发布带来极大的可能。
在实际工作过程中, 测试用例在设计过程中过分依赖于被测软件, 只能在软件升级及改进的时候可以加以利用;测试用例之间一般都会存在或多或少的联系, 如有些测试用例的运行取决于其它测试用例的运行结果;每个测试工程师在设计测试用例的时候都有自己的喜好, 对测试用例的格式和结构也没有一个统一的定义, 并且对测试用例没有统一进行管理, 描述也不太充分, 这些都为测试用例的复用带来了很大的困难。
1 研究现状
随着人们对软件产品质量的重视程度的加强, 软件测试在软件开发中的重要性也越来越突出, 在软件开发中所占的成本也逐渐提高, 对于一些安全性较高的软件, 如银行系统等, 软件测试费用会所占的比重会更高。
测试用例的设计作为软件测试过程的核心, 它的优劣直接影响了软件测试的效率, 而测试用例的设计在很大程度上取决于测试人员的经验等, 如何利用已有的资源对测试用例进行重用避免软件测试过程中的重复工作, 提高软件质量, 就显的很有必要了, 很多学者对测试用例的复用进行了研究。
文献[1]提出了通过抽取测试用例操作步骤的关键词, 将其提炼为可复用的测试项集合的方法来实现对测试用例的复用, 此方法降低了测试用例复用与被测功能的相关性, 但是只是对测试用例的输入域进行复用, 对测试用例设计的思想, 设计步骤没有办法复用。文献[2]从测试用例的分类着手, 针对其具有的共性以及面向对象语言的特点, 将面向对象系统中的测试用例依据设计方法分为状态检查测试用例和状态比较测试用例, 进而提出了一个统一的测试用例生成、执行模式, 使测试用例能够独立于被测对象, 在理论上讨论了通过使用统一的调用模式, 以达到测试用例复用的目的。文献[3]针对第三方测试机构的特点给出了一种测试用例复用过程模型, 对测试用例进行统一建模组织, 并进行有效管理的思路。文献[4]提出了一种测试复用机制, 通过对测试用例进行可复用描述, 得到可复用的测试用例, 并利用刻面树作为逻辑结构, 生成测试用例库, 通过用例库的各种功能实现用例的复用。文献[5]给出了基于形式规格说明的测试用例库, 增强测试用例库中用例的复用程度。文献[6]针对航天测控软件的特点, 介绍了面向复用的测试用例的结构、组织方式, 用例复用的流程等技术, 实现了测试用例的管理和复用。
以上文献对测试用例可复用性的研究, 都把测试用例的描述作为研究重点, 分析测试用例可复用特征, 通过不同的测试用例复用策略, 生成不同程度的可复用测试用例库, 该文在上述研究的基础上, 对可复用测试用例的概念、设计思想进行详细分析, 给出了可复用测试用例库的模型, 对提高测试用例的复用程度有很好的效果。
2 测试用例复用
2.1 测试用例复用的概念
软件复用是指利用已开发成功的值得借鉴的成果、经验来开发新的软件产品的过程, 整个软件开发中的一切优秀成果都可以进行复用, 包含软件测试过程, 软件测试复用主要是重复利用测试过程中产生的测试理论、测试思想、测试策略、测试用例及测试文档等等。其中对软件测试的核心——测试用例的复用将会提高测试的效率。
测试用例的复用就是在软件测试过程中利用已经存在的测试用例的过程, 根据测试用例被复用的程度, 可以分为直接复用和改进复用, 如果搜索出来的测试用例与需求完全一致, 则直接复用现有测试用例, 一般情况下, 直接复用测试用例的情况很少, 如果搜索出来的测试用例与需求近似, 则对现有的测试用例进行修改和继承, 得到一个新的测试用例之后再复用, 即改进复用。
2.2 测试用例复用的类型
按照测试用例的复用[5]类型, 可分为以下几种:
1) 同一软件在不同测试阶段的测试用例复用
在项目开发过程中, 底层测试对象的测试用例可能部分地复用到高层对象的测试中, 例如单元测试的测试用例可以用到集成测试中。
2) 同一软件在不同时间测试下的测试用例复用
在项目开发过程中, 随着应用的推广, 新的需求会被提出来, 那么就会出现这种产品的多个版本, 在对一个软件多个版本的测试中, 如果软件在上一次测试过程中产生的大量测试用例被保存下来, 在新的一次测试中, 可以查询找到相关的测试用例, 进行测试用例的复用, 缩短了软件产品的升级时间及提高了后续版本的质量。
3) 类似软件之间的测试用例复用
同类软件的测试用例在设计思想、测试策略、测试数据、及测试步骤等都有类似之处, 通过借鉴原有的测试用例对发现被测软件的缺陷, 测试效率的提高有很大的帮助。
2.3 可复用测试用例的设计思想
要实现软件测试过程中对测试用例的复用, 必须满足以下条件:首先应该存在用于复用的软件测试用例, 如果没有测试用例可供选择, 对测试用例的复用将无从谈起;其次可复用的测试用例是有效的, 能够为将来的软件测试提供服务, 测试用例的描述应该完整, 并与被测软件的相关性降低到最小, 这样的测试用例才能满足将来的软件测试需求;最后软件测试工程师了解可复用测试用例的使用方法, 才能更好的实施测试用例的复用。在实际操作过程中, 需要对测试用例的结构有一个良好的定义, 这样才能在测试环境发生改变的时候, 测试用例能够继续利用, 那么在设计可复用的测试用例的时候要遵循的指导原则如下:
1) 测试用例之间的相关性尽量降低到最低;
2) 测试用例对被测软件的依赖尽量减弱;
3) 测试用例的描述要规范化;
4) 测试用例尽量不包含常量, 输入值用变量代替;
5) 测试用例的内容要完整, 结构要统一;
6) 测试用例的分类要合理。
3 基于复用的测试用例库模型
实现软件测试用例复用的有效途径就是建立一个测试用例库, 并按照适合领域、类型等进行多级合理的分类、组织、存储, 以便进行查找和利用现有测试用例。
软件测试的目的是尽可能的发现软件的缺陷, 发现缺陷越高的测试用例, 越有复用的必要, 在测试用例库的设计中添加测试用例发现的缺陷描述, 这样在复用测试用例的时候, 优先选择易于发现软件错误的优质测试用例;对于优质的测试用例, 被复用的测试也会越来越多, 那么, 在以后的测试用例的选取上, 也尽量选择复用次数较高的测试用例;对于复用效果好的测试用例, 或者对于测试用例复用的时候的一些心得体会也很重要, 可以指导后面的测试用例的选取, 在测试用例的结构中添加复用人的评论也至关重要。
随着测试用例库中的用例逐渐增加, 测试用例库逐渐庞大起来, 为了提高测试用例的搜索效率, 对于部分复用次数较少的测试用例, 或随着技术的不断改进, 对于不再具备实际运行的条件而成为过时的测试用例, 可将其删除或者移动到历史用例库。
在测试用例库中对测试用例发现的缺陷进行排序, 可以对相似类的软件系统所出现的缺陷有一定的预测作用。在复用测试用例的时候, 优先选择易于发现缺陷的测试用例和数据。
4 总结
软件测试对于软件产品质量的高低起着至关重要的作用, 如何提高软件测试的效率已经越来越影响软件产品是否能够按时发布, 作为软件测试的核心——测试用例的设计将变得更为重要。为了缩短软件测试的时间, 就需要重复利用以往的先进经验成果, 即复用测试用例。测试用例的复用程度, 取决于测试用例设计的独立程度及是否规范, 并且有一个有效的对测试用例进行规范管理的测试用例库。该文对可复用测试用例的设计思想进行详细分析, 提出了可复用测试用例库的模型, 对测试用例的复用有很好的效果。
摘要：软件测试是提高软件质量的关键步骤, 测试用例的设计又是软件测试的核心, 对已有的优秀的测试用例进行复用能够缩短软件测试的时间, 该文对介绍了可复用测试用例的概念及设计思想, 提出了可复用测试用例库的模型, 提高了测试用例的复用程度。
关键词：测试用例,复用,软件测试,测试用例库
参考文献
[1]胡珊, 杨丰玉, 张晔, 等.基于测试项抽取的测试用例复用方法[J].微电子学与计算机, 2010 (1) .
[2]徐仁佐, 陈斌, 陈波, 等.构造面向对象软件可复用测试用例的模式研究[J].武汉大学学报:理学版, 2003 (5) .
[3]卜国峰, 孙志刚, 丁小良.软件测试用例的复用研究[J].四川兵工学报, 2009 (5) .
[4]肖寒, 顾春华.一种基于Z规格说明的测试用例复用机制[J].计算机应用与软件, 2009 (12) .
[5]张红燕, 杨根兴, 蔡立志.基于形式化描述可复用测试用例库的研究与实现[J].计算机应用与软件, 2010 (7) .
可复用的网上评教系统研究 篇4
学生评教是检测教师教学质量的一个手段, 相比欧美国家, 我国学生评教起步较晚, 到20世纪90年代初才得到高校普遍认可和重视, 并逐步成为教师教学质量评价的主要方式。随着计算机技术和网络技术的飞速发展, 网上评教在模式和规模都有了很大的改善, 方式也日趋完善, 但仍存在一些问题: (1) 单纯有学生评教, 学生乱评、代评影响评教结果公平性的现象。 (2) 针对不同科目评教缺少相对公平; (3) 评教量化表的制定缺少规范性, 量表的改变就将导致整个评教系统程序的改变, 操作复杂。本文针对上述问题设计一个可复用的网上评教系统, 在此系统上, 对量表进行改变, 不会影响程序的运行。
一、系统的整体设计方案
1、整体设计上, 由学生的单一评教, 改为由学生、教学质量与评估部、教师所在学院三方分别打分, 根据三部分的权重, 综合评定教师的教学质量。在系统中, 为最大程度实现系统的灵活性, 减少程序的修改, 将各部门打分权重设置成可更改的, 当修改三个部分的权重比例时, 不影响系统的运行。
2、评教量化表的设计。学生评教量表的科学性从根本上决定评教结果的准确性, 评教量表的设计反映到评教系统中就是评教问题的选择和设置。在本系统中, 设置成可变的问题设置模式, 在修改评教问题时不需要修改程序, 使得程序有很强的复用性。
3、对量表问题的权重设置。在评教问题中, 各个问题对于评教结果的影响因子可能不同, 对于那些更能反映教师教学水平的量化分值要高些, 相应的相对影响小的分值要低些;同时, 问题的回答对评教结果的影响应该也是不同的。因此, 在系统中, 设置问题—答案权重量化表, 可根据用户的选择对不同问题设置不同的量化标准, 还可以将目前已有的教学质量评估评价模型的成果应用于本系统中。
4、对问题答案的限制。系统中对每个问题设置A, B, C, D四个答案, 为避免学生恶意评教或敷衍评教, 系统可限制评教用户对选A, B, C, D答案的数量进行限制, 例如可避免全选A或者全选D的现象。
5、尽可能避免因为科目之间的差异而造成的评教结果的不公平性。由于课程之间的差异, 导致学生对教师教学的评价无法按照统一的标准。
6、将学生评教与学生查成绩系统连接, 不完成本学期的评教就无法查询成绩, 最大限度的保证学生参与评教的参评率。
二、数据库设计
要实现上述系统设计中谈到的各模块的系统功能, 在网上评教过程中, 由多个部门针对不同的科目的任课教师进行教学质量评估, 实现评教的科学性, 建立合理的数据库是关键。在系统中建立的主要数据库表11个, 具体如下:
用户信息表:记录用户的基本登录信息, 用户所属的角色权限;
学生信息表:记录学生基本信息, 所在班级, 学生所有的上课信息记录等;
课程基本信息:记录教师任课情况, 教师所在院系, 学时, 教授的课程信息等;
评教问题基本信息表:记录每个评教问题的具体内容, 根据不同答案所占的评分权重值;
各类评教用户所占权重比例表:记录学生、教学监督、教师所在学院在评分结果中所占的评分比重;
评教问题答案数量限制:记录评教答案中A, B, C, D各选项所占的比例;
科目优秀率设置表:记录某些限制学科优秀率的人数;
学生评分结果表:记录学生学号等学生基本信息, 课程名称、任课教师等课程信息, 学生评的某们课程的成绩, 包括每个问题的答案, 留言等内容;
教学监督部门评分结果表:记录监督部门对教师的评价结果;
教师所在学院评分结果表:记录教师所在学院对教师评价结果;
评分结果总表:记录通过计算得出的各个任课教师获得的最终成绩以及教师排名。
三、网上评教系统的实现
本系统以ASP为开发平台, Sql Server2000为后台数据库, 采用B/S模式, 运行于校园网络系统平台上, 各用户通过浏览器访问Web服务器, Web服务器再根据客户机的需要通过ADO访问数据库, 本系统中Web服务器为IIS5.0。服务器通过使用ASP处理接收到的客户端的请求, 通过ADO连接建立数据库, 返回相应的信息并发送到客户端的浏览器, 实现用户与服务器数据库的交互工作。
在用户登陆时, 用户在客户端提交用户名和密码、用户角色权限信息, 进行身份认证, 认证通过后将用户信息存入session中。本系统采用多级用户不同权限的管理模式, 用户权限分配方案采用文献[5]中的方法, 用户登录系统时, 按照session中存的信息, 调出不同的功能权限, 进行评教, 数据统计、排名, 权重设置, 评教问题设置等操作。各模块的开发上采用传统ASP语言开发, 这里特别说明, 本系统的可复用性, 其中的代表就是问题-权重的灵活设置, 避免因为修改评教量化表而引起的系统程序变动。
四、小结
本文分析了目前的网上评教系统的现状, 针对根据评教量表设计评教系统, 对量表的修改时需要修改评教系统的不够灵活的缺点, 设计实现了一套可复用的网上评价系统, 同时针对目前只由学生对教师授课质量进行评价不够全面的问题, 提出由学生、学院、监督部门三方全面衡量教师的教学质量。
摘要：评教量化表的设计在网上评教中对教师教学质量评估结果起着至关重要的作用, 目前已有的评教系统中, 没能将量化表设计独立出来, 量化表的改变导致整个系统程序的改变。针对这个不足, 本文设计了一个不依赖于量化数据的可复用的网上评教系统, 并提出了符合设计的数学模型和数据库设计方案。另外, 针对只有学生评价教师可能出现的评教不公平现象, 本文提到的系统采用学生、教学监督部、学院三方按照比例对教师进行评价。
关键词：网上评教,可复用的,评教量化表,教学质量评估
参考文献
[1]张爱梅、王胜霞:《关于网上评教的调查与对策》, 《教育探索》, 2010, 4 (9) 19-20。
[2]李伟娟:《高职院校学生网上评教的实践与探索》, 《教育与职业》, 2010, 4 (11) 170-172。
浅谈软件复用 篇5
传统的大型应用软件的主要特点有:重复编码式开发方式和一次开发持续运行的应用软件。重复编码式开发方式, 使快速开发企业级应用软件难以实现。一次开发持续运行的方式, 导致了软件的僵化和濒危。
我们不妨参考PC电脑硬件设计:它由一块主板和一系列的设备部件组成。无论是CPU、内存条、显卡、声卡、U盘, 只要符合一定的标准就可直接在主板上进行插拔和替换。如果软件框架可以做得像主板, 软件组件做得像设备部件, 那么软件就可以像硬件一样实现快速组装和大规模生产。这实际上就是软件复用所追求的终极目标。
2 软件复用基本概念介绍
2.1 真正的软件复用
在软件演化的过程中, 重复使用的行为可能发生在三个方向上:时间上, 使用以前的软件版本作为新版本的基础, 加入新功能, 适应新需求;平台上, 以某平台上的软件为基础, 修改其和运行平台相关的部分, 使其运行于新平台;应用上, 将某软件 (或其中构件) 用于其他应用系统中, 新系统具有不同功能和用途。
这三种行为中都重复使用了现有软件。但是第一种复用实际上是软件维护, 第二种实际上是软件移植, 都不能算真正的软件复用。第三种复用是为了支持软件在应用方向上的演化, 使用“为复用而开发的软件 (构件) ”来更快、更好地开发新的应用系统, 这才是真正的软件复用。
2.2 软件复用的发展
复用概念的第一次引入早在1968年, Mc Ilroy在其论文《大量生产的软件构件》中提出。在此以前, 子程序的概念也体现了复用的思想, 但目的是为了节省当时昂贵的机器内存资源, 并不是为了节省开发软件所需的人力资源。然而子程序的概念可以用于节省人力资源的目的, 从而出现了通用子程序库, 供程序员在编程时使用。
2.3 软件复用的关键
分析传统产业的发展, 其基本模式均是符合标准的零部件 (构件) 生产以及基于标准构件的产品生产 (组装) , 其中, 构件是核心和基础, “复用”是必需的手段。标准零部件生产业的独立存在和发展是产业形成规模的前提, 软件产业发展完全可以借鉴这种模式。软件产业要发展并形成规模, 标准构件的生产和构件的复用是关键因素。这正是软件复用受到高度重视的根本原因。
3 软件复用的实现方法
3.1 与软件复用相关的技术
软件复用技术是一系列的相关技术的综合运用, 包括软件构件技术;领域工程、软件构架技术;软件再工程、开放系统技术;软件过程、CASE技术以及一些非技术因素。实现软件复用的各种技术因素和非技术因素是互相联系的, 它们互相结合共同影响软件复用的实现。
3.2 软件构件技术
构件是指应用系统中可以明确辨识的构成成分, 具有相对独立的功能和可复用的价值。可复用构件应该具有如下特点:
独立性:构件可独立开发、部署和发布, 软件构件是一个软件组装单元;
有一组定义良好的接口:构件通过一组接口对外完成其功能, 接口可分为对外服务接口和服务请求接口;
封装性:构件是一个高内聚的软件包, 通过接口对外交互, 屏蔽了内部实现细节, 构件可通过独立开发封装为符合业界认可的模型标准的二进制代码。当前构件封装采用的标准有:微软的COM+和.NET、SUN公司的Java Bean和EJB、国际组织的CORBA等;
可替换性:构件被组装到软件系统中后, 可以用具有相同接口和相同封装标准的其他构件将其替换, 替换中无须编码, 不影响系统运行;
可组装可调整性:构件可以在定义良好的体系结构下方便地组装到软件系统中, 也可以与其他构件组装成为粒度更大的构件。一般情况下, 构件要有方便的可调整机制以便于复用, 即提供多个可变点以利于客户化。
3.3 领域工程
为了能够很好的实现软件复用, 复用必须是系统化的。系统化复用的成功依赖于很多因素, 其中领域工程是系统化软件复用成功的关键。
通过领域工程, 将某一特定领域的知识转化成为一组规约、构架和相应的可复用构件。由于这些信息来自于同一领域中现有的系统, 因此它们具有较高的可复用性, 而且当一个领域中的应用系统增加了的时候, 通过领域工程, 可以对这些系统进行新的分析, 将新系统的特征也包含在规约、构架和可复用构件中, 从而使本领域系统开发的知识和经验尽可能地积累到复用基础设施中, 以促进新系统的开发。领域工程对于系统化软件复用的意义还在于, 领域工程不仅产生了可复用性较高的构件, 而且通过产生构架定义了复用时机和复用的上下文。这样对开发者复用这些构件提供了有力的支持, 使得复用变得规范、系统和高效。
3.4 软件构架
通过对软件构架的研究, 有利于发现不同系统在较高级别上的共同特性;从构架的层次上表示系统, 有利于系统较高级别性质的描述和分析。特别重要的是, 在基于复用的软件开发中, 为复用而开发的软件构架可以作为一种大粒度的、抽象级别较高的软件构件进行复用, 而且软件构架还为构件的组装提供了基础和上下文。软件构架研究如何快速、可靠地通过可复用构件构造系统的方式, 着重于软件系统自身的整体结构和构件间的互联, 对于成功的软件复用具有非常重要的意义。
3.5 软件再工程
软件再工程是指对既存对象系统进行调查, 并将其重构为新形式代码的开发过程。最大限度地重用既存系统的各种资源是再工程的最重要特点之一。再工程的主要工作是对既存系统中非可重用构件的改造。软件再工程的思想实际上和回收业的“变废为宝”的思想是十分相近的。
软件再工程是一个工程过程, 它将逆向工程、重构和正向工程组合起来, 将现存系统重新构造为新的形式。再工程的基础是系统理解, 包括对运行系统、源代码、设计、分析、文档等的全面理解。但在很多情况下, 由于各类文档的丢失, 只能对源代码进行理解, 即程序理解。
4 基于复用的软件开发过程
软件复用技术研究 篇6
软件复用是指利用现有的软件资源来构造新的软件系统。该软件成分可能是己有的构件,也可能是专门开发设计的可复用的软件构件。其中,可复用的现有软件成分是软件复用技术的核心。复用成分的获取、管理和利用是构成软件复用技术的三个基本要素。通过软件复用,在应用系统开发中可以充分利用己有的开发成果,消除了在分析、设计、编码、测试等方面的重复劳动,可以提高软件开发的效率;同时,通过复用高质量的已有的开发成果,避免了重新开发可能引入的错误,可以提高软件的质量。因此,软件复用可以大大降低软件开发的费用,并显著地提高生产效率和产品质量。
2 软件复用的主要思想
将软件看成是由不同功能部分的“组件”所组成的有机体,每一个组件在设计编写时可以被设计成完成同类工作的通用工具。这样,如果完成各种工作的组件被建立起来以后,编写特定软件的工作就变成了将各种不同组件组织连接起来的简单问题,这对于软件产品的最终质量和维护工作都有本质性的改变。
3 软件复用的实现
软件复用有三个基本问题,一是必须有可以复用的对象;二是所复用的对象必须是有用的,三是复用者需要知道如何去使用被复用的对象。软件复用包括两个相关过程:可复用软件(构件)的开发(Development for Reuse)和基于可复用软件(构件)的应用系统构造(集成和组装)(Development with Reuse)。解决好这几个方面的问题才能实现真正成功的软件复用。前者是生产可复用构件的过程,后者是利用现有的可复用构件生产新系统的过程。可复用构件为有计划地、系统地进行复用提供了手段,是实现软件复用的基石。
4 软件复用的关键技术
实现软件复用的关键因素主要包括:软件构件技术、领域工程、软件构架、软件再工程、开放系统、软件过程、CASE技术等,以及各种非技术因素。实现软件复用的各种技术因素和非技术因素是互相联系的,它们结合在一起,共同影响软件复用的实现。
1)软件构件技术:软件构件技术是支持软件复用的核心技术。
2)软件体系结构:软件体系结构(Software Architecture)也称为架构,它是对软件系统的系统组织,是对构成系统的构件的接口、行为模式、协作关系等体系问题的决策总和。研究软件体系结构有利于发现不同系统的高层共性,保证灵活和正确的系统设计,对系统的整体结构和全局属性进行规约、分析、验证和管理。
3)领域工程:领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程,它覆盖了建立可复用软件构件的所有活动。领域是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。领域工程包括三个主要的阶段:领域分析、领域设计以及领域实现。
4)软件再工程:现存大量的遗产软件系统由于技术的发展,正逐渐退出使用,如何对这些系统进行挖掘和整理,得到有用的构件;己有的构件随着时间的流逝会逐渐变得不可使用,如何对它们进行维护,以延长其生命期等等。软件再工程正是解决这些问题的主要技术手段。
5)开放系统技术:开放系统技术的基本原则是在系统的开发中使用接口标准,同时使用符合接口标准的实现。它为软件复用提供了良好的支持,使构件可以方便地以“即插即用”的方式组装到系统中,实现黑盒复用。这样,符合接口标准的前提下,构件就可以独立地进行开发,从而形成独立的构件制造业。
6)软件过程:软件过程又称软件生存周期过程,是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。一个良好定义的软件过程对软件开发的质量和效率有着重要影响。基于构件复用的软件开发过程和传统的一切从头开始的软件开发过程有着实质性的不同,所以探讨适应于软件复用的软件过程成为迫切的问题。
7)CASE技术:CASE技术对软件工程的很多方面都可以提供有力的自动或半自动支持。软件复用同样需要CASE技术的支持。CASE技术中与软件复用相关的主要研究内容包括:在面向复用的软件开发(Software Development)中,可复用构件的抽取、描述、分类和存储、提取组装、可复用构件的度量等等。
5 软件复用的过程
可以归纳为抽象、选取、实例化和集成四个部分。抽象是指对可复用软件资源的概括和提炼;选取是寻找、比较和选择最合适的可复用软件资源;实例化是指对软件资源的修改并形成它的实例;集成是将选定的已实例化的可复用软件资源组合成完整的软件系统。所以,软件复用过程可以概括为:一个用为复用所开发的可复用软件的资源来创建或集成软件应用程序和系统的过程。这样的复用过程将软件开发分成两个阶段:可复用软件资源的生产阶段和基于可复用软件资源的应用系统开发阶段。可复用软件资源的生产阶段对应于领域工程,进行可复用软件资源的分析、设计和实现;基于可复用软件资源的应用系统开发阶段对应于应用系统,利用可复用资源对应用系统进行分析、设计和实现
6 基于可复用构件的应用系统的开发
软构件模型是关于开发可重用软构件和构件之间通信的一组标准的描述。通过重用己有的构件,使用构件对象模型的软件开发者可以像搭积木一样快速构造应用程序。这样不仅可以节省时间和经费,提高工作效率,而且可以产生更加规范,更加可靠的应用程序。
基于可复用构件的应用系统的开发一般包括以下步骤:
1)进行系统调查和需求分析,明确和系统交互的人员、外部系统,也就是确定系统边界和问题域,同时明确系统要完成什么功能、表达什么信息,即表示系统责任;
2)对系统的每个USECASE进行流程分析,即明确每个USE CASE的实现流程;
3)采用面向对象分析方法,并结合每个USECASE的SEQUENCE框图和COLLAB A l ON框图,建立系统的CLASS框图(包括对象层、特征层和关系层),CLASS框图中的每个方法只需定义出接口,即输入、输出什么参数,而不包括实现细节,把具体的实现(包括程序框图、实现代码)留到设计阶段去做;
4)在建立系统的CLASS框图之后,综合考虑系统责任、系统的体系结构、开发平台,建立系统的构件模型;
5)设计构件。在设计构件之前,查询可复用构件库,对己有构件(相同的直接复用,相近的通过修改复用)进行复用,对于新构件进行设计。新构件设计包括接口设计(LOL文件设计)、每个功能的程序框图设计、算法设计以及复杂算法的伪代码;
6)实现新构件,使用以构件库中的可复用构件为核心开发的构件,建立应用系统;
7)系统测试与运行。将系统移植到相应的分布式环境中进行测试,对问题进行修改,直到满足用户要求。
7 发展趋势
软件工程技术日益普及,软件、平台、环境开始广泛使用。软件复用和软件构件技术受到广泛关注。采用基于软件复用的软件构件,将使软件设计、生产工厂化成为可能,是未来软件开工具发的发展方向,软件复用和软件构件技术是解决软件危机,提高软件开发效率和质量的有效途径,是一种社会化的软件开发方法。软件复用和软件构件技术将引起软件产业的深刻变革,尤其是近年来,网络的兴起为大型软件的分布式开发带来了得天独厚的条件,软件产品的国际化水平将不断提高。因此,该技术一定会有良好的发展前景。
参考文献
[1]陈菲,刘克勤.计算机软件复用技术研究[J].现代电力,2002,19(6):95-101.
[2]王少锋,何志均,王克宏.软件重用技术研究[J].计算机工程与设计,2000,21(5):10-15.
[3]曾广周,孙红梅.基于软件构件的软件开发方法研究[J].计算机研究与发展,1998,35(11):991-995.
[4]徐珊娜.基于复用技术的构件研究与实现[D].西安建筑科技大学硕士论文,2007.
浅议软件复用技术 篇7
随着软件需求的激增、软件规模和复杂度的不断增大, 大量资源被浪费在重复开发上, 传统的开发方法无法适应用户在质量、效率等方面对软件的需求。软件复用又称软件重用或软件再用, 是指重复使用“为了复用目的而设计的软件”的过程, 是利用现有的软件成分来构造新的软件系统的过程。近十年来软件复用被认为是解决软件危机、提高软件生产率和质量的最有效和最具潜力的手段。
2 软件复用简介
软件复用不仅仅是对程序的复用, 还包括对软件生产过程中任何活动所产生的制成品的复用, 如项目计划书、可行性报告、需求分析、概要设计、详细设计、编码 (源程序) 、测试用例、文档与使用手册等等。按抽象程度的从低到高, 软件复用可以被划分为如下5个级别[1]:
(1) 代码的复用, 包括目标代码和源代码的复用。当前大部分编程语言的运行支持系统都提供了连接 (Link) 、绑定 (Binding) 等功能来支持目标代码的复用。源代码的复用级别略高于目标代码的复用, 程序员在编程时把一些想复用的代码段复制到自己的程序中, 但这样往往会产生一些新旧代码不匹配的错误。大规模的实现源代码的复用只有依靠含有大量可复用构件的构件库, 如”对象链接及嵌入” (OLE) 技术。
(2) 设计的复用。这种复用有三种途径, 第一种途径是从现有系统的设计结果中提取一些可复用的设计构件, 并把这些构件应用于新系统的设计;第二种途径是把一个现有系统的全部设计文档在新的软硬件平台上重新实现, 也就是把一个设计运用于多个具体的实现;第三种途径是独立于任何具体的应用, 有计划地开发一些可复用的设计构件。
(3) 分析的复用。可复用的分析构件是针对问题域的某些事物或某些问题的抽象程度更高的解法, 受设计技术及实现条件的影响很少, 所以可复用的机会更大。复用的途径也有三种:从现有系统的分析结果中提取可复用构件用于新系统的分析;用一份完整的分析文档作输入产生针对不同软硬件平台和其它实现条件的多项设计;独立于具体应用, 专门开发一些可复用的分析构件。
(4) 测试信息的复用, 主要包括测试用例的复用和测试过程信息的复用。前者是把一个软件的测试用例在新的软件测试中使用, 或者在软件作出修改时在新的一轮测试中使用。后者是在测试过程中通过软件工具自动地记录测试的过程信息, 包括测试员的每一个操作、输入参数、测试用例及运行环境等一切信息。
因为软件的开发过程主要是从抽象级别较高的形态向抽象级别较低的形态演化的正向过程, 所以较高级别的复用容易带动较低级别的复用。开发者可充分利用其它已有的分析件和设计件, 自己设计或编程, 完成系统的剪裁、扩充、维护、演化等活动。
3 实现软件复用的关键技术因素
软件复用的过程实际上是一系列的相关技术的综合运用过程。这些技术包括软件构件技术、领域工程、软件构架技术、软件再工程、开放系统技术、软件过程、CASE技术以及一些非技术因素。实现软件复用的各种技术因素和非技术因素是互相联系的, 它们互相结合共同影响软件复用的实现。
3.1 领域工程、软件构架技术
可复用信息依赖于特定的问题和特定的问题解决方法, 具有领域特定性。为此, 在识别、获取和表示可复用信息时, 应采用面向领域的策略。领域的需求具有一定的稳定性, 使得获取的信息可以在较长时间内多次复用。领域工程是一组相似或相近系统的应用工程建立基本能力和必备基础的过程, 覆盖了建立可复用软件构件的所有活动, 可划分为以下三个阶段[2]:
(1) 领域分析。这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同需求。这个阶段的主要活动包括确定领域边界, 识别信息源, 分析领域中系统的需求, 确定哪些需求是被领域中的系统广泛共享的, 哪些是可变的, 从而建立领域模型。
(2) 领域设计。这个阶段的目标是获得领域构架 (Domain-Specific Software Architecture, 简称DSSA) 。DSSA描述了领域模型中表示需求的解决方案, 它不是单个系统的表示, 而是能够适应领域中多个系统需求的一个高层次的设计。建立了领域模型之后, 就可以派生出满足这些被建模的领域需求的DSSA。由于领域模型中的领域需求具有一定的变化性, DSSA也要相应地具有变化性。
(3) 领域实现。这个阶段的主要行为是定义将需求翻译到由可复用构件创建系统的机制。根据所采用的复用策略和领域的成熟和稳定程度, 这种机制可能是一组与领域模型和DSSA相联系的可复用构件, 也可能是应用系统的生成器。
这些活动的产品 (可复用的软件构件) 包括:领域模型、领域构架、领域特定的语言、代码生成器和代码构件等。
研究实践表明, 软件复用在特定领域内更容易获得成功。因此, 领域工程受到高度重视, 已有许多研究成果。有代表性的工作包括卡耐基梅隆大学的软件工程研究所 (CMU/SEI) 提出的面向特征的领域分析方法 (Feature Oriented Domain Analysis method, 简称FODA) , 它支持对某领域中系统共性和个性的发现、分析和文档记录。
对于软件架构, 目前还没有一个统一的定义。典型定义是, 软件架构是对构成系统的构件接口、行为模式、协作关系等体系问题的决策总和。研究软件构架有利于发现不同系统的高层共性, 保证灵活和正确的系统设计, 对系统的整体结构和全局属性进行规约、分析、验证和管理。
这样, 在基于复用的软件开发中, 为复用而开发的软件构架可以作为一种大粒度的、抽象级别较高的软件构件进行复用, 而且软件构架还为构件的组装提供了基础和上下文。构架描绘的是系统的蓝图, 是沟通软件需求与软件设计的一座桥梁, 使软件复用从代码复用发展到设计复用和过程复用。
3.2 软件再工程、开放系统技术、软件过程
现存大量的遗产软件系统由于技术的发展, 正逐渐退出使用, 如何对这些系统进行挖掘和整理, 得到有用的构件;己有的构件随着时间的流逝会逐渐变得不可使用, 如何对它们进行维护, 以延长其生命期等等。软件再工程正是解决这些问题的主要技术手段。软件再工程是一个工程过程, 它将逆向工程、重构和正向工程组合起来, 将现存系统重新构造为新的形式[3]。再工程的基础是系统理解, 包括对运行系统、源代码、设计、分析、文档等的全面理解。但在很多情况下, 由于各类文档的丢失, 只能对源代码进行理解, 即程序理解。
开放系统技术的基本原则是在系统的开发中使用接口标准, 同时使用符合接口标准的实现。开放系统技术为软件复用提供了良好的支持。特别是分布对象技术使得符合接口标准的构件可以方便地以“即插即用”的方式组装到系统中, 从而实现黑盒复用。这样, 在符合接口标准的前提下, 构件就可以独立地进行开发, 从而形成独立的构件制造业。
软件过程又称软件生存周期过程, 是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。一个良好定义的软件过程对软件开发的质量和效率有着重要影响。然而, 基于构件复用的软件开发过程和传统的一切从头开始的软件开发过程有着实质性的不同, 探讨适应于软件复用的软件过程自然就成为一个迫切的问题。
3.3 CASE技术等以及各种非技术因素
计算机辅助软件工程 (Computer Aided Software Engineering, 简称CASE) 可使系统按照开发商规定的应用规则, 由计算机自动生成合适的计算机程序。软件复用同样需要CASE技术的支持。CASE技术中与软件复用相关的主要研究内容包括:可复用构件的抽取、描述、分类和存储;可复用构件的检索、提取和组装;可复用构件的度量等等。
除了上述的技术因素外, 软件复用还涉及人的素质、教育、法律等非技术因素问题, 如:知识产权问题;保守商业秘密的问题;复用前期投入的经济考虑;标准化问题;机构组织如何适应复用的需求;管理方法如何适应复用的需求;开发人员知识的更新;创造性和工程化的关系;开发人员的心理障碍等等。
3.4 软件构件技术
基于构件的软件复用是迄今为止最优秀的软件复用手段, 是支持软件复用的核心技术, 并在近几年迅速发展成为受到高度重视的一门学科分支。构件技术的应用必须遵循一些共同的规范, 当前流行的有OMG的CORBA、SUN的EJB和微软的DCOM。
构件是具有内部结构和功能的软件构成元素, 可通过标准接口独立提供特定服务, 并且可由一些连接器及相关规则与其它构件组装成符合要求的新软件或构件。从抽象程度来看, 面向对象技术已达到了类级复用, 因为它是以类为封装单位的。但这样的复用粒度还太小, 不足以解决异构互操作和效率更高的复用。构件将抽象的程度提到一个更高的层次, 它是对一组类的组合进行封装, 并代表完成一个或多个功能的特定服务, 也为用户提供了多个接口。整个构件隐藏了具体的实现, 只用接口对外提供服务。
因此, 在基于构件的软件开发方法下, 程序开发模式也相应地发生了根本变化, 不再是“算法+数据结构”, 而是“构件开发+基于构架指导的构件组装”。基于构件的软件开发过程 (Component-based Software Development, 简称CBSD) 有五个主要的组成部分:需求分析、构件库、 (下转第3页) (上接第17页) 构件的获取、构件的复用、构件的组装。计算机软件开发技术从面向对象技术 (OO) 和分布式面向对象技术 (DOO) 发展到软件构件技术, 并向构件技术方向演变, 软件构件以至组件技术为应用软件产品化提供了理论基础, 这是应用软件产业化发展的基本方向。
4 结束语
国际上, 软件复用在领域工程、构件及构件库的标准化、构件组装技术、基于复用的软件开发过程和复用成熟度模型等方面已经取得了重大成功。国内的相关研究也较多, 如北京大学软件工程研究所提出的青鸟构件模型, 它的目标是致力于软件复用, 以构件作为软件复用的基本单位, 提供一种有效的管理和检索构件的工具。
参考文献
[1]张韧志, 田丽芳, 葛文庚.软件复用探讨[J].电脑知识与技术, 2009, 5 (23) :6452-6453.
[2]张友生, 等.软件体系结构[M].清华大学出版社, 2006.11:6.