翻译计算机外文期刊请高人帮忙翻译附件里
摘要：
没有确切的试验证据证明面向对象系统的可维护性，某种程度上因为还没有用于早期研究的目标和系统的典型代表。对于目前正在被软件专业人员使用和维护的使命关键软件，我们从经验上来分析其维护性这一问题。 这里考虑功能上等同的两个版本的信用卡审批系统，一个是面向对象的，一个是非面向对象的。发现面向对象的系统可以比非面向对象的系统花费更少的时间维护更多的软件。在整个软件发展生命周期中这种差别在各个阶段都有。 这个结果是将UML用于面向对象版本系统的影响分析得到的，这样有助于高效的理解和通信。非面向对象的不完善的设计规范会使得在将设计方案转换到进一步发展时出现模糊或者高费用的缺点。而且面向对象的...全部
摘要：
没有确切的试验证据证明面向对象系统的可维护性，某种程度上因为还没有用于早期研究的目标和系统的典型代表。对于目前正在被软件专业人员使用和维护的使命关键软件，我们从经验上来分析其维护性这一问题。
这里考虑功能上等同的两个版本的信用卡审批系统，一个是面向对象的，一个是非面向对象的。发现面向对象的系统可以比非面向对象的系统花费更少的时间维护更多的软件。在整个软件发展生命周期中这种差别在各个阶段都有。
这个结果是将UML用于面向对象版本系统的影响分析得到的，这样有助于高效的理解和通信。非面向对象的不完善的设计规范会使得在将设计方案转换到进一步发展时出现模糊或者高费用的缺点。而且面向对象的封装技术会减少因维护而带来的脑力劳动量并可以实现代码复用，另一方面，需要管理的文件数量的增加和附带管理也要强面向对象的技术，此外面向对象的设计运行起来比较协调，但它比非面向对象的运行速度要慢。
为了构成背景因素，如方法、过程和维护工具，需要有更多的软件工程师研究领域。
普遍认为，面向对象范例的使用增加了软件的可维护性（Johnson，2000）。然而这些优点还没有在实验上被证实，虽然为了证明这一结论人们已经做了许多实验，但是迄今为止证明的结果并不理想（Johnson，2000）。
而且，事实上所有的研究都是基于一个比较容易控制的实验室，这个实验室是建立在专门为了实验而开发的一些软件上，所以并不能就此推断这些实验结果也适用于现实世界的软件，再者几乎所有的实验都是基于研究的而不是基于软件工程师的。
本文给出了一个软件维护实验，该实验基于一个运作着的现实世界的使命关键系统。一个系统是基于结构范例用C开发的，另一个是基于面向对象的用C++开发的。两个系统都同时被一些软件工程师维护。
第二章讨论了关于该论题的相关研究。
第三章强调了本文所做的研究是基于现实世界的而不是实验室软件。第四章给出了实验的细节，第五章给出实验结果。第六章说明了实验中的技术差异，第七章指出了面向对象系统的性能，第八章是总论和结论。
2。
可维护性和面向对象范例
如同在ISO/IEC 12007(1995)中的定义，因为出现运行问题，或者需要进一步提高软件质量，或者要使软件有更好的适用性，而对软件代码和相关连文档进行相应的修改，这一过程就是软件维护。
根据这个可行的定义，不管是在软件的安装之前还是安装之后，无论何时，只要软件出现了错误，或者使用者的需求改变了就会引发软件维护。随着IEEE标准改进成与ISO/IEC1 2007，电气和电子工程师协会和电子工业联合会后来都采用了这一定义(IEEE/EIA,1998)。
因此，可维护性也可以随之这样定义：为了更改某个错误或者适应变化了的需求，一个软件系统或者软件产品可以被修改，这就是可维护性。
现在考虑可维护性的面向对象范例的影响。面向对象范例包含许多特征，例如类、对象、继承、多态和动态封装。
我们应该知道这些特征对于可维护性的影响分别是什么。首先考虑继承。对于继承树的高度如何影响可维护性的实验结果都相互矛盾。例如，Daly et al。(1996)发现三层继承的面向对象软件比没有继承的面向对象软件维护起来花费的时间少很多。
可是同样的实验Cartwright (1998)却发现了相反的效果。Harrison et al。(2000) 接着用零层继承、三层继承和5层继承做了一个类似的实验，发现没有继承的软件修改起来更容易。
最近Prechelt et al。(2003)指出完成确定维护任务的时间随着继承层数的增加出现上升趋势。
这些相互矛盾的结论在Freeman and Schach (in press)那里得到了缓解，他们指出在三层继承实验的一系列实验结果中继承对于可维护性的影响是依赖于任务的。
实验中用到了两个功能等同的C++程序，一个是继承树型结构，另一个是水平结构。一个维护任务在继承型结构上更容易执行，而另一个任务却在水平结构上更容易些，第三个在两个结构上的执行结果基本相同。
对于面向对象范例其他特征（如类、对象、多态和动态封装）对可维护性的影响我们没有任何的实验证明结果。
在反例被证明之前可以相信这些特征的影响效果也是任务依赖的。如果这个结论是正确的，那么那些相反的实验结果就可以得到解释。但即使其他因素没有任务依赖的影响，继承影响显然是任务依赖型的实事也很难说明面向对象范例是如何影响可维护性的。
3。 现实世界和实验室软件
对于面向对象范例对可维护性影响的实验研究 (包括Briand et al。,1997。2001:Cartwright,1998;Daly et al。,1996;Deligiannis et al。
,2003,2004;Freeman and Schach,inpress;Harrison et al。,2000;Prechelt et al。,2003)一般是学生做的，而不是软件工程师。
实验系统小，从几百到几千行代码，参与实验的人知道他们的目标，所以实验结果很通常出现Hawthorne效应偏差(Gillespie,1993)。最后，试验也通常是在一些专门为此结果而写的软件上，而且维护任务是人工完成的。
相反，我们的研究是为了检测软件工程师在实践中维护的使命关键操作软件的方法（试验系统的细节见4。1节）。实验中所用的改变的需求是从现实的改变需求中随机抽取的，参与者不知道他们所做的维护任务是什么实验目的。
考虑到面向对象范例的多面性，单个实验结果可能不是面向对象软件的普遍结果，所以本文的目标就是要在我们实验中提供尽可能多的信息， 这里给出的结果可以和将来一些维护实验的结果结合起来，试验是基于现实世界的软件，并被一些研究员操作，以便于可以得到统计上正确的面向对象技术对可维护性影响的实验结果。
4。 实验细节
4。1 系统细节
该研究源于韩国的一个主要的信用卡公司，2003年，该公司的年度销售总额大约为分期付款购货250亿美元、先进垫付470亿美元。销售额大部分经由现实的刷卡交易（大部分零售店都可以做，例如加油站、饭馆等）完成，而且全国有大约3000种零售渠道。
每天平均的交易数量使得容错系统的使用、用于为大约2000万公司信用卡持有者服务的Tandem Himalaya服务器(12 CPU)成为必要。
实验是在这个由专业人员维护的使命关键身份识别系统上进行，作为一个数据源系统移动的结果，我们用两个功能相同软件，一个是C++设计的面向对象的，另一个是C和TAL（汇编程序）设计的面向结构的。
下文中用OO代表面向对象系统，用NOO代表非面向对象系统。
实验参与者的可用文档见表1。两组都有相同的维护任务需求规范，保留的需求规范是专门针对那些扩展的范例的。NOO一组使用数据流图和作业描述来描述系统，另一方面OO组用UML，即用例图和描述，来描述商业功能。
对于设计和分析，NOO组有一个程序功能模块和他们之间相互关系的标单，这与OO组的类图是等同的。而且OO组还使用操作规范，这些规范用来描述操作细节，例如，操作名，标识，组成要素，前置条件，后置条件，用伪代码写的程序逻辑。
NOO组很可能在某些表面的水平导出他们的影响分析，对于细节分析他们宁肯参考源代码，另一方面OO组是被动要求分析的，操作规范和类图的结果（体现了参与类和接口的思想）可能就是为什么OO组能够达到更容易修改、更少费用误差的原因。
NOO组文档中记录的NOO分析的产品列表和设计阶段必须得以应用，这类似于OO组中的程序描述文档，它给出了逻辑和物理文档之间的关系图。
两组在实现阶段和测试阶段的测试用例上都用到源代码，最后一个阶段，配置计划为配置各自的编译程序用的目录结构提供文档。
4。3 维护任务的细节
这个实验中的维护任务是从488个变更请求（CR）中随机选取的，所有的提交的CR都有IT计划署从可行性和有效性方面进行了评估，每个CR都标有某个1到9的数字用以从技术和管理两方面来反映这些资源的状况，从而衡量这些资源在满足变更的必须性。
被标记成最高两个水平的CR（即标记成1和2）是相对于政府策略或者外部环境的变更而言的，这种变更的满足估计需要几个人月；从3到5的标记水平一般需要大约一个人月；6和7一般与增加一到两个用户接口显示有关；最低的水平8和9是相当简单的，大约需要几个人日就可以完成。
大部分的CR看起来好像更小，水平8和9大约占所有CR的50%，只有大约10-20%的CR标记到水平4或者以上（见表2）。
这个研究中用的维护任务是信贷限制整合（CLI），这里的CLI是从水平4的CR中随机选取的一个现行CR。
每个客户都被提前分配了各自的用以信用卡和现金垫款的信贷限制，CLI的目的就是为每个客户引入一个全局的信贷限制。
4。4 参与者细节
有12个IS专家参与了该实验，其中的六个被分派到NOO组，他们是这个信用卡公司的IS职员，在过去的几年中一直从事与该公司的传统系统的维护，所以非常了解CLI的相关活动和过程；其他六个IS专家被分到OO组，因为涉及到用面向对象的范例和C++重新组建原有系统的全部过程，他们也被看作是CLI的专家，就如同NOO中的成员一样。
4。5 程序细节
首先向参与人员下达维护命令，告诉他们应该记录维护细节，包括时间和人力耗费。我们的实验目标就是要在尽可能避免人工控制的情况下检测维护实验的状态，所以我们不会要求参与者改变他们的维护过程，而是尽量的观察他们的维护过程。
因为维护任务在两个操作系统上执行，所以这些参与者的IS管理员会解释这项任务的重要性并让两个组尽可能精确的记录他们的详细过程，但是，参与者没有被告知他们的任务是整个实验的一部分，所以他们会认为他们的记录和报告只是他们日常事务的一部分，这样实验结果就不会受到Hawthorne效应(Gillespie,1993)的影响。
4。6 因变量
从OO和NOO组收集的数据用于计算两个维护性量度(Briand et al。,2001)：第一个量度是人分钟的总效力，用来理解、修改、测试CLI所需要耗费的人工的；另一个量度是软件的变更量，变更量如下测试：
文档中的变更的页数；
执行代码的修改行数；
构造的测试用例数；
构造测试程序的代码的行数；
要编译的文档数；
要配置的文档数。
对实验室中的维护实验来说，参与者足够可以指出他们觉得需要做什么变更，他们没有必要完成这些变更，也没有必要检查这些导出软件是否无故障、是否满足更改的要求。相反，CLI维护是一个需要给出评价系统的现行的变更，所以两个组都要求成功的完成CLI维护任务，两个量度以及需求、分析、设计、执行、测试和调度都要在整个系统的发展生命周期中完成。
两个测度，效力和变更量，就是这里的因变量。
4。7 数据有效性
在维护任务完成之时就要对效力记录作仔细核对，进行面谈以理清任何表面上的多报或者少报的内容，这样所有股东就会组织组会以弄清效力数据的任何错误；更改量数据用预排的方法进行检查核对，这种方法要求所有参与者和管理人员都参加。
5。 结论
我们首先比较了前三个时期（需求、分析、设计阶段）的可维护性，表3的第三和第四栏说明了总的效力（单位是人分钟），可以看出这三个时期中NOO组的效力大约是OO组的两倍（1260 VS 570人每分钟），尤其是分析和设计阶段NOO组大约需要三倍于OO组的效力(1,020 vs。
310人每分钟)。所以，在前三个阶段用OO范例可以大大降低维护所要用的效力资源。（表3的数据反映的是相关的技术效力，我们没有包括管理效力）
从表3还可看出在分析和设计阶段的变更量OO组要大于NOO组，这是因为OO组有更多的软件要维护，而NOO组只有几个强制性文档。
OO组修改了UML的一些文档，例如活动图表、用例图表、类图表，因为模型的广泛使用，我们得出顺序图表也有很多的重复性操作所以价值不大。UML不能表达商业细节，所以商业细节在操作规范文档中给出，另一方面NOO组几乎不能给任何用户需求建立文档，它依赖于口头通信。
意外的是OO组花费了更少的效力资源，这在第7部分进行了讨论。总之，OO比NOO用了更少的效力但是用了更多的文档变更。
现在比较后三个阶段（执行、测试、调度）的可行性。从表4可以看出，在执行阶段NOO的效力大约是OO组的三倍(660 vs。
215人每分钟)，而OO组通过使用足够的文档好像更节省时间，NOO组不得不重新确立自己的机能。对CLI需求，NOO组在实现功能性上用的策略好像目前系统的剪贴版本。即使在这个阶段，他们依旧要经常和系统分析员和商业用户口头讨论不明确的需求，而且大量的时间被耗费在下面这些全局变量的大量使用上：
Card Swipes（一种使用安全卡片或识别码来取得通过的物理控制技术）的输入流；
外部文件声明保存的共享的常量合数组。
而且令人吃惊的是NOO组在测试阶段的投入大约是OO的六倍还多，尽管NOO组用的测试用例只是比OO组的一半稍少（15 vs。 39），OO范例的优势一直保持到调度阶段，这一阶段NOO组投入了大约两倍于OO之多的效力资源（30 vs。
17 人每分钟）。和前三个阶段一样结果表明OO用例可以降低维护的效力资源。
现在看表4的变更量数据，在执行阶段修改的可执行代码行数NOO组（182）少于OO组（277）。分别考虑信用卡支付和先进垫付时，结果令人吃惊：对信用卡支付，NOO只修改了51行执行代码，而OO却修改了268行；相反，在现金垫付中，更改的执行代码NOO为131而OO仅仅是9行。
这一现象主要因为OO中的代码复用，即一个组件（信用卡支付）的商业逻辑稍作修改就可以用于另一个组件（现金垫付），而NOO中每个组件的商业逻辑都是分别独立建立的。
最后的测试阶段，OO创建了由283行代码组成的扩展测试程序，这些代码用于用C++语言编写的源代码文件单元（CppUnit），这样就如同前述，降低了测试的效力资源。
表4还可以看出，OO不得不编译和调度更多的文件，这是因为类的较好的粒度性。综合考虑，尽管有更多的文件，OO却有更少效力的优点。
6。 技术的不同
两个组的维护过程的主要不同是他们在构建各自的评价系统所使用的方法的不同引起的。
NOO用结构化的方法，并且使用C实现，这样NOO成员就要在C中实现，并用结构化方法和CASE工具；而OO使用UML和UP(Unified Process)，并用面向对象的CASE工具在C++中实现。
起初三个阶段（需求、分析、设计），OO主要依靠UML，而NOO须要系统分析员和维护人员的直接交流。这影响了两个组的影响分析的效果，NOO组不得不通过阅读已有原代码来理解CLI，而OO组将检测UML图表（包括用例图，类图，顺序图）的变化。
明显的不同还存在于维护的执行和测试阶段，OO的维护人员会在必须确定要对系统做什么修改时提出设计文档，他们也会检测包含了专门为这一目的而写的足够的商业规范的操作规范；然而NOO的维护人员必须依靠系统分析员，但这样在分析员和维护者之间来回传递设计结果的直接交流方式增加了企业的管理费用。
完成修改以后，两个组就会生成类似的测试用例，可是两个组使用的技术是不一样的。NOO生成一个模拟器，把每个保存在数据库中的测试用例提供给系统，并在测试结果日志中存储结果；OO使用用CppUnit写的测试程序，这一程序会自动将测试结果保存到日志中。
7。 性能分析
在测试性能前，先保证OO和NOO给出的事物测试用例是一样的，同样的对拒绝事物，我们用内部软件模拟器构建生成测试用例。开始，从先前几年的商业操作中收集了测试数据构成了100个测试用例，一旦初始测试通过，我们就逐步将测试用例增加到一百万个，这个过程显示了需要修改调整的许多误差和错误。
下面检测作为一个整体的这两个版本软件结构的性能，包括CLI任务，快速的周转时间对于评价软件很有必要，这一限制下的故障也会导致对软件设计和结构的检测(Balsamo et al, 2004)。
因为OO的性能持续低于NOO，信用卡公司最后决定，考虑到客户的利益，购买额外的大约100万美元的计算机资源，包括一对CPU，还有一个磁盘存储器和一个软件许可(为 Tandem中间件准备)。
无疑地，公司决定为了节约将来的维护成本，花费100万购买计算机资源是值得的。也就是说，这个实验反映了对于信用卡公司，一个面向对象的系统比一个等价的非面向对象系统更具有可维护性。
8。 讨论和结论
这个研究发现总体上，修改时OO组成员比NOO可以花费更少的效力并保持更多的软件资源，软件生命周期中无论哪个阶段资源被明显的有效利用了，这一发现好像和那些比较面向对象和非面向对象软件发展的试验结果（包括Boehm-Davis and Ross, 1992; Hadar and Hazzan, 2004; Pennington et al。
, 1995）相矛盾，可是那些使用时处理软件发展的，而我们的是研究软件维护的。
OO技术在软件维护上的优点可以归功于用于影响分析的UML的使用，而且，检测UML效率的试验，如Hadar and Hazzan, 2004; Purchase et al。
, 2001，在维护的过程中没有执行。
The end!。收起
