文獻(xiàn)翻譯(英文).doc

黃河科技學(xué)院畢業(yè)設(shè)計(jì)(論文)文獻(xiàn)翻譯 第 7 頁 An empirical investigation of the impact of the object-oriented paradigm on the maintainability of real-world mission-critical softwareSource Journal of Systems and Software Volume 77 , Issue 2 (August 2005) Pages: 131 - 138 Year of Publication:2005 ISSN:0164-1212 Authors Joa Sang Lim School of Media Technology, Sangmyung University, Seoul, South Korea Seung Ryul Jeong The Graduate School of Business IT, Kookmin University, Seoul, South Korea Stephen R. Schach Department of Electrical Engineering and Computer Science, Vanderbilt University, Nashville, TNPublisher Elsevier Science Inc. New York, NY, USA Abstract Empirical evidence for the maintainability of object-oriented systems is far from conclusive,partly due to the lack of representativeness of the subjects and systems uesd in earlier studies.We empirically examined this issue for mission-critical software that was currently operational and maintained by software professtionals.Two functionally equivalent versions of a credit approval system were maintained,one object oriented (OO) and the other non-object oriented (NOO).We found that the OO group took less time to maintain a greater number of software artifects than its NOO counterpart,This difference held for all phases of the software development lift cycle.This result was due to the usefulness of UML for impact analysis of the OO version,which contributed to effective comprehension and communication. Insufficient design specifications for the NOO version led to ambiguity and costly defects in transferring design solutions to development.Also the encapsulation of the OO version appeared to reduce mental loads for maintenance tasks and resulted in code reuse.On the other hand,the number of files to be managed increased and,thus,dependency management was required for the OO version.Furthermore,despite much tuning,the OO version ran slower than its NOO counterpart.More field studies on software professionals are needed to compare contextual factors such as methods,processes,and maintenance tools. It is widely believed that use of the object-oriented paradigm incresases software maintainability (Johnson,2000).However,this supposed benefit has not as yet been experimentally balidated.A number of empirical studies have been performed to address this issue,but the results to date have been inconclusive (Johnson,2002).Furthermore,virtually all the studies have been conducted in a well-controlled laboratory setting on software specially developed for the experiments,and it is not clear that these results can be extrapolated to real-world software.In addition,almost all the experiments have been performed on students,rather than on software professionals. In this paper we describe a maintenance experiment performed on two versions of an operational real-world mission-critical system.One version was developed in C using the structured paradigm, the other in C+ using the object-oriented paradigm.Both versions were main-tained by teams of software professionals. In section 2,we discuss related research on this issue.In Section 3 wo stress that our research was performed on real-world software,not laboratory software.The details of our experiment appear in Section 4,andthe results in Section 5.Differences in technologies are discussed in Section 6,and performance concerns of the object-obiented system in Section 7.Section 8 contains a discussion and our conclusions.1.Maintainability and the object-oriented paradigm As defined in ISO/IEC 12007(1995),maintenance is the process that occurs when software undergoes modifications to code and associated documentation due to a problem or the need for improvement or adaptation.In terms of this operational definition,maintenance occurs whenever a fault is fixed or the requirements change,irrespective of whether this takes place before or after installation of the produce.TheInstitute for Electrical and Electronics Engineers (IEEE) and the Electronic Industries Alliance (EIA) subsequently adopted this definition (IEEE/EIA,1998) when IEEE standards were modified to comply with ISO/IEC12007.Accordingly,maintainability may be defined as the ease with which a software system or product can be modified to correct a fault or conform to changed requirements. We now turn to the impact of the object-oriented paradigm on maintainability.The object-oriented paradigm encompasses a number of distinct features,such as classes,objects,inheritance,polymorphism,and dynamic binding.We need to know the impact on maintainability of each of these features.First consider inheritance.The results of empirical studies as to how the height of the inheritance tree affects maintainability have been mutually contradictory.For example,Daly et al.(1996) found that object-oriented software with three levels of inheritance took significantly less time to maintain than equivalent object-based software with no inheritance.However,a replication of this experiment described by Cartwright (1998) found the opposite effect.Harrison et al.(2000) then performed a similar experiment using zero,three,and five levels of inheritance and found that modification was easier on the version with no inheritance.More recently.Prechelt et al.(2003) showed that the time to perform certain maintenance tasks tends to increase as the number of levels inheritance increases. These contradictory results were reconciled by Freeman and Schach (in press),who showed in a series of three experiments that the impact of inheritance on maintainability is task-dependent.Two functionally equivalent C+ programs were constructed,one with an inheritance hierarchy and the other flat.One maintenance task was easier to perform on the version with the inheritance hierarchy,a second task was easier on the flat version,and a third task was equally easy to perform on both versions. We are not aware of any empirical evidence regarding the impact on maintainability of other features of the object-oriented paradigm,such as classes,objects,polymorphism,and dynamic binding.Until evidence to the contrary has been obtained,it is not unreasonable to believe that these features may also have a task-dependent effect.If this is indeed the case,it would explain the contradictory empirical results on the maintainability of software development suing the object-oriented paradigm.But even if the other features do not have a task-dependent effect on maintainability,the fact that the impact of inheritance is apparently task-dependent makes it hard to determine how the object-oriented paradigm affects maintainability.2. Real-world versus laboratory software Empirical studies on the effect of the object-oriented paradigm on maintainability,including (Briand et al.,1997.2001:Cartwright,Daly et al.,1996;Deligiannis et al,2003,2004;Freeman and Schach,inpress;Harrison et al.,2000;Prechelt et al.,2003),have generally been performed on students,rather than on software professionals.The experimental systems were small,ranging from a few hundred to at most a few thousand lines of code.The participants were aware that they were subjects,so the results could have been biased by the Hawthorne effect (Gillespie,1993).Finally,the experiments were generally perormed on software specially written for that purpose,and the maintenance tasks were artifical. In contrast,our study was designed to examine the way professionals maintain mission-critical operational software in practice (details of the system on which our experiment was performed appear in Section 4.1).The change request that formed the subject of our experiment was randomly selected from the set of actual change requests,and the participants were not told that the maintenance task they were to perform was the subject of an experiment. In view of the multifaceted nature of the objuect-oriented paradigm,the results of the sigle experiment we describe here cannot be generalized to object-oriented software in general.Instead,the aim of this paper is to provide as much information as possible about our experiment, in the hope that the results presented here can be combined with those of a variety of future maintenance experiments, performed on real-world software be a variety of researchers,to arrive at statisically valid conclusions as to the impact of object technology on maintainability.3.Details of the experiment3.1 System details This study was conducted in a field setting at a major credit card company in Korea.In 2003,the annual sales volume of the company was about $25 billion for installment purchases, and $47 billion for cash advances. The sales were generally logged via real-time credit card swiping transactions that occurred at numerous member stores(e.g.gas stations,restaurants,etc.) and about 3,000 retail channels all over the nation. The average number of daily transactions necessitated the use of fault-tolerant systems and Tandem Himalaya servers (12 CPU) to service the approximately 20 million card holders of the company. The experiment was performed on the mission-critical credit approval system maintained by professionals. As a consequence of migrating a legacy system, two functionally equivalent versions of the software were operational; the object-oriented version was implemented in C+, the structured version in C and TAL (assembler).In what follows, we use the abbreviation OO to refer to the object-oriented version of the software, and NOO to the non-object-oriented version. The documentation available to the participants is summarized in Table 1.Both groups were given the same requirements specification for the maintenance task. The remaining requirements documents were specific to the paradigm for which they had been developed. The NOO group utilized flow charts and job descriptions that had been drawn up to describe the overall system. On the other hand, the team responsible for developing the OO version had detailed the business functions using UML, namely, use-case diagrams and descriptions. Turning to the analysis and design phases, the NOO group had a list of program functions (modules) and their mutual dependence. This was equivalent to the class diagrams of the OO group. In addition, the OO group utilized operation specifications, which documented such operational details as operation name, signatures, constituent components, preconditions, postconditions, and grogram logic written in pseudocode. The NOO group appeared to conduct their impact analysis at a somewhat superficial level; they preferred to rely on the source code for the detailed analysis. On the hand, the OO group members were required analysis. The resulting operation specifications, together with a class diagram that showed a view of the participating classes and interfaces, might have been the reason why the OO group was able to locate the part to be modified more easily, and had fewer costly defects. The production list of the NOO analysis and design phase showed the files the NOO group had to deploy. This was similar to the grogram traceability document of the OO version, which showed the mappings between logical and physical files. Both groups utilized source code during the implementation phase and test cases during the test phase. For the last phase, the deployment plan documented the directory structure to deploy the respective compiled programs.3.2 Maintenance task details The maintenance task performed in this experiment was randomly chosen from a pool of 488 change requests (CR).In more detail, all CRs submitted were evaluated by the IT planning department with regard to feasibility and validity. Then, each CR was assigned a number between 1 and 9 to reflect the resources, both technical and managerial, that were estimated to be needed to implement that change. CRs assigned to the two highest levels, 1 and 2, generally corresponded to changes in government policy or the external environment that were estimated to require several person-months to implement. The next levels. 3 through 5, were assigned to CRs that usually would require about one person-month of effort. CRs at levels 6 and 7 were usually con