A study of the impact of C++ on software maintenance

Transcription

1 A study of the impact of C++ on software maintenance Dennis Mancl AT&T Bell Laboratories Warren, NJ William Havanas AT&T Bell Laboratories Columbus, OH Abstract This is a case study of the impact of the C++ programming language and object oriented design on the maintenance phase of a software development project. The results show increased software reuse and reduced complexity of software changes in the parts of the project that use object oriented design. 1. Introduction The goal of this study is to show the maintenance phase impact of designing a software system using object oriented design and coding the system in C++. This system, henceforth called CXR, is a system that is written part in C and part in C++, so it offers an cxcellent opportunity to compare the maintainability of software written in the two languages. Actually, most of the comparisons that are made in this paper compare subsystems that have been written in different styles rather than in different languages - this study is an attempt to evaluate the differences between object oriented programming and conventional structured programming. The results of this study should help projects that are in the early phases of design, who need to understand how much C++ s data abstraction and object oriented programming capabilities will affect their overall systems cost. The measurements in this paper identify some of the places where object oriented programming had a significant impact on increasing productivity and reducing complexity in the maintenance phase of the CXR project. The productivity of the CXR programmers was increased because they were able to reuse a large amount of existing code. The complexity in making changes to CXR s object oriented parts was lower - new features were added to CXR with fewer changes to existing function interfaces, for example. The measurements in this paper will attempt to quantify the amount of software reuse and the level of complexity of software changes. 2. Some information about CXR CXR is a medium-sized software system that supports some of the operation of telephone company central office equipment. It currently consists of about onehalf C code and one-half C++ code, plus some shell scripts, form definition files, help files, and other miscellaneous code. CXR uses C++ in different ways in different segments of the system. In some parts of the system, the C++ compiler is used to provide argument type checking for code written in C. In other parts, C++ is used to build data abstractions. A data abstraction is a collection of data structure definitions and a set of subroutines that implement a well-defined interface to the data structures. In some CXR code, C++ is used to implement an object oriented design. In an object oriented design, data abstractions are built in a hierarchy. New classes are built from existing general classes instead of being built completely from scratch. CXR is a typical small development project - a group of development programmers wrote the first version of the system some time ago. A team of programmers has been responsible since then for maintenance of the system. This team fixes bugs found in the field, develops new code for adapting to changes in the systems with which CXR communicates, and builds new features needed by customers. Maintenance is not a completely accurate term for the activities of the current CXR team, unless the term is redefined to mean a broader set of activities. In fact, most software engineering texts give a broader definition of maintenance that includes more than just bug fixes. Lientz and Swanson give three major categories of maintenance activities: corrective maintenance adaptive maintenance, and perfective maintenance/ ]. In their study, they estimate that maintenance activities, on the average, are 21% corrective, 25% adaptive, 50% perfective, and 4% other activity. (The numbers for CXR, based on number of lines of code modified for each MR class, are roughly the same: 30% corrective, 13% adaptive, and 57% CH2921-5/90/0000/0063$01.OO IEEE 63

2 perfective.) The perfective and adaptive activities, the development of new features or the elaboration of existing features, are a place where object oriented design has a positive impact. 3. Class census of CXR CXR was developed in a combination of languages (C and C++) using a combination of programming paradigms (conventional structured design, abstract data types, and object oriented design). As the system has evolved, an increasing amount of the CXR code is in C++ class definitions. The following tables summarize this growth in the use of C++ s major mechanism for structuring data and functions: version file count source (.h;.c) lines (ncsl) CXRl 348(148;200) CXR2 599(247;352) CXR3 599(247;352) CXR4 830(332;498) CXR5 867(347;520) lines of class code TABLE 1. CXR files and classes summary version number of number of classes derived classes CXRl CxR cxr cxr cxr TABLE 2. CXR derived classes summary I version % class code lines of code I per class CxRl cxr cxr cxr TABLE 3. CXR class code summary The ratio of derived classes to the total number of classes is changing slowly - it is close to 1:3 for all of the releases in the table. The percentage of class code in CXR is steadily increasing. Many new features in CXR have been added by building new classes - some of them are classes derived from existing classes. Some parts of CXR have been redesigned to use C++ better. These redesigned subsystems define more data abstractions and use more of the standard C++ libraries. 4. CXR software reuse In the past two years, between CXR3 and CXR5, the amount of C++ class reuse savings has doubled. This level of reuse has allowed the functionality of the CXR system to be greatly increased with only a modest increase in the number of lines of code. The total size of CXR during this time only increased by 40% (see Table l), but without the extra reuse, CXR s size would have increased 93% (see Tables 3 and 4). CXR has obtained reuse benefits from the use of C++ in three different ways. First, CXR has used many of the standard C++ libraries throughout the system. Character strings are stored and manipulated with the String library, associative tables use the Map library, and linked lists use the List library[*]. These libraries have been very useful, saving a considerable amount of development work. For the purposes of this study - in order to focus on the reuse benefits of C++ based on code that the CXR project wrote themselves - only the reuse savings from CXR s own classes will be counted. Second, the CXR team has developed many of their own general-purpose and special-purpose C++ class libraries. The use of these classes by multiple programmers on the project has avoided the development of duplicate functionality in different parts of the system - similar code developed by different developers because of poor communication and documentation. The table below summarizes the reuse savings from CXR-developed class libraries. Reuse is counted in terms of reused lines of code - any class that is used in more than one subsystem of CXR is counted here as being reused. version total reused reuse code class code savings (CXRdeveloped) CXR % CXR % I CXR % TABLE 4. CXR regular class reuse Third, CXR contains an increasing number of derived classes - classes that are built from other classes using inheritance. Table 1 shows that the number of derived classes has been increasing over time. A simple measure of the amount of inheritance reuse is a count of the total number of lines of code in the classes that a derived class inherits from. The following table summarizes this inheritance reuse measurement for three different releases of CXR. 64

3 ~ in version total reused reuse code class code savings (inheritance) CXR % CXR % CXR % TABLE 5. CXR inheritance reuse What is the impact of reuse on the development of CxR5? Suppose that CXR5 had been developed with no further exploitation of regular class reuse or inheritance reuse. The total size of CXR5 would be increased by = if there were no additional use of regular class reuse, and the total size would be increased by = if there were no additional use of inheritance reuse. As a result, CXR5 would have been lines instead of lines - or a 93% increase over CXR3 instead of a 40% increase. 5. CXRMRdata This study continues with some information about the differences in the cost of maintenance caused by different programming paradigms. To get information about these differences, it is necessary to look at the parts of the CXR system that have been changed. All changes in CXR are made through Modification Requests (hereafter referred to as MRs). The CXR project has been recording all modification requests and has been logging all source code changes since January The following data was collected from inspecting CXR MRs. For each MR, the subsystem or subsystems affected by the MR was determined. Each MR has been classified as an accommodation because of external change, a bug fix, or an MR that introduces new features to a subsystem. These MR classes correspond to the adaptive, corrective, and perfective maintenance activities cited in section 2. In addition, each MR is checked to determine if any interfaces are changed. The interface is said to be changed if there is any change to either internal or external interfaces including global variables, changes in function arguments, either type or number, and changes in return values. If there is a change in an interface, the programmer usually has to do more work performing the change the programmer has to be careful to check every module or subsystem that may depend on that interface. A high ratio of MRs that cause interface changes is an indication that the structure of the system does not provide adequate data hiding. The complete data is in an internal memo131. The table below is a summary of information about the CXR MRs. Each MR is associated with a CXR process. There are 58 processes in CXR. Each process is assigned to a category: OOP (object oriented programming), - ADT (abstract data type), or - structure (conventional structured programming). All processes written entirely in C are assigned to the structure category. Processes written in C++ are assigned to the OOP category if they use inheritance to define new classes, the ADT category if they use C++ classes without inheritance, and the structure category if they use C++ without defining new classes. The miscellaneous category contains the MRs that fit into none of the other categories - MRs that affect database scripts, screen form descriptions, and other data files. 22.5% ADT 58.8% misc 1.9% total % I TABLE 6. MR analysis summary OOP - object oriented programming ADT - abstract data types structure - standard C type structured programming misc - other files including several specialized CXR script languages The MRs can also be divided into three classes based on their root cause: - MRs that are accommodations because of external change (13.8% of the total MRs) - MRs that are related to bug fixes (65.6%), and - MRs that introduce new features (20.6%). The following table shows the proportion of MRs that change the interface: 65

4 Proportion of MRs that change the interface - OOP modules Proportion of MRs that change the interface - structured modules i 25% I TABLE 7. MR breakdown by class and by interface changes 6. Comparison of interface changes Why is this data interesting? Interface changes are responsible for very complex software modifications, while the changes required when no interface change takes place are often localized to a single subsystem or module. An interface change might be only partially performed - this can cause subtle problems, for instance, when a function is called with the wrong number or types of arguments. Reducing interface changes saves modification and testing effort. The data in the previous section show that in the OOP modules there is a significant reduction in the number of MRs that cause interface changes. The following are the proportion of MRs that changed interfaces in the OOP and structured programming categories. MRs with interface change in OOP modules: 22.5% MRs with interface change in structured programming modules: 37.7% The z test is used to compare the proportion of logic fixes. The z test value for this data is 3.80, which corresponds to a 99.99% significance level. There are significant differences in the proportion of changed interfaces caused by accommodations and by bug fixes, but there is a striking difference in the proportion of changed interfaces in the set of MRs that introduce new features. In the OOP modules, only 40.9% of the new feature MRs produced an interface change. On the other hand, in the structured programming modules, 73.8% of the new feature MRs had an interface change. Using the z test to compare these proportions, the z test value for this data is 3.40, which corresponds to a 99.97% significance level. The greatest impact of object oriented programming on reducing the amount of interface change is in the development of new features, which usually accounts for about one-half of the work in the maintenance phase. No comparison can be made for the abstract data types sections of CXR because there is not enough MR data to make a statistical comparison. 7. Another type of MR comparison Another set of estimates of the amount of work per MR is based on measuring the size and distribution of the changed code. This section will look at the differences in the number of lines changed, the number of files changed, and the number of contiguous code blocks changed per MR. For the CXR system overall, this data is inconclusive - with apparently contradictory results generated by each of these approaches. This section presents a description of the measurement method, the actual data with some qualitative analysis, and finally some statistical analysis of this data. The first way to measure the amount of work involved in resolving an MR is to count the number of source lines changed for the MR. This measurement puts the most emphasis on long or complex code that is added - this occurs most often when new features are added to a system. A second way to measure the amount of work involved in resolving an MR is to count the number of files modified for the MR. Counting the number of files changed is an easy measurement to perform, since the names of the modified files are stored in the MR database. It gives an indication about how much work was done in reserving the source files for update, and it gives a naive estimate of the amount of work in crosschecking the changes in a collection of files. This model assumes that simple changes modify only one source file and complex changes modify many source files. A third way to measure work is to count the number of contiguous blocks of code that are changed. This is a compromise measurement. Adding a new function counts as one block changed, just the same as a single line logic fix. But for many software fixes, it is much easier to add a small block of code in one place than to add an equivalent number of lines scattered throughout a file. Small scattered changes are dominant in the 66

5 Average lines per file 191 I 302 Average number of lines modified per MR n OoP 8.6 structure OOP ADT structure TABLE 8. Average source lines per file by category The following table shows that the number of source lines modified per MR is lower for OOP modules. The number of source lines modified is significantly lower for the accommodations to change MRs. The number of MRs in each category is lower in this table than in Table 5, because this table only includes MRs that caused changes to C or C++ source files. MRs that only changed database scripts, screen form descriptions, and other data files are not being considered here. In the following tables, a stands for accommodations to external change, b stands for bug fixes, and f for new features. Average number of lines modified per MR OOP structure 224 I I TABLE 9. Summary of source lines modified per IvfR Not surprisingly, bug fixes cause relatively small changes and new features made changes that were somewhat larger. The main difference between the OOP MRs and the structure MRs in this table is found in the accommodations to change column - the structure MRs resulted in many more lines changed. The accommodations MRs in the object oriented parts of the system are more like bug fixes, and they are more like new features in the structured programming part of the system. The following table contains the data for the second measure described above: the count of the number of files modified per MR. I TABLE 10. Summary of files modified per MR The number of files per MR is considerably greater for the OOP modules. This data suggests that the average OOP MR requires more work than the average structure MR, which contradicts the previous measurement of the number of lines modified per MR. Actually, two major factors are at work here. First, the number of lines per file is significantly smaller in the CXR OOP code than in the rest of CXR. Second, object oriented programming in C++ makes heavier use of header files than ordinary structured programming. This causes frequent changes to the header file that defines the structure of a class (especially when there is an interface change) as well as the source file that defines the class s functions. (In fact, there were 1.2 header files modified per OOP MR and only 0.37 header files modified per structure MR.) The table that follows shows that the number of files modified per MR is much higher for the MRs where the interface was changed. 1 category 1 interface changed? of process OOP structure Yes no 2.33 files/mr 1.31 files/mr TABLE 11. Files modified per MR based on interface change The third metric discussed above looks at the number of contiguous code blocks changed. This measure may also clarify the apparent discrepancy between the first two measurements. The rationale for this metric is that it is usually easier to change a small block of contiguous lines than to change an equal number of lines that are scattered throughout a program. The table below summarizes the number of code blocks modified per IvfR for the different MR types. The number of code blocks modified can be found by counting the number of modification commands output by the diff program. I 61

6 category of process OOP class of MR a b f total blocks/mr 1 structure I I 18.2 blocks/mr I TABLE 12. Summary of code blocks modified per MR For this measure, there is no overall difference between OOP and structure MRs. There are two major statistical results in this data. First, analyzing the differences in total lines per MR and blocks per MR, there is a significant difference in the number of lines per MR between the OOP MRs and structure MRs (z = 1.77, so the difference is significant at the 96% confidence level), but no significant difference between the number of blocks modified per MR (z = 0.105), and a significant increase in files per MR for the OOP MRs (2 = 2.94). Fewer lines per change in the OOP modules reflect the benefits of software reuse. The increase in the number of files changed per MR for OOP modules seems to be due to a change in file structure - the similarity in the number of blocks changed per MR indicates that the use of object oriented programming has not caused an increase in number of small changes throughout the system. Second, the difference in the accommodations to change MRs is very striking. As expected, the number of source lines changed for new feature MRs is significantly greater than that for bug fix MRs (z = 3.37 for OOP new feature versus OOP bug fix; z = 3.78 for structure new feature versus structure bug fix - both are at the 99.9+% confidence level). But the average number of source lines modified for OOP accommodations MRs is not significantly different from that for OOP bug fixes ( z = 0.472). On the other hand, the average number of source lines modified for structure accommodations MRs is significantly greater than that for structure bug fixes (2 = 2.34, which corresponds to a 99% confidence level). These two results show some of the benefits of the object oriented paradigm. The first result, a decrease in the number of lines modified per MR with no change in the number of blocks modified per MR, shows that data abstraction is at work. The data abstractions in the C++ classes raise the level of the language used in the code. One class member function call often can replace several lines of regular C code. The second result demonstrates that the OOP code is more flexible - the complexity of the average adaptive change is not significantly different from the complexity of the average corrective change. 8. Redesign of the CXR dbload processes As part of the effort to compare structured design methods with object oriented design methods, the CXR team redesigned one of the most troublesome subsystems in CXR - the dbload processes. There are currently eight different dbload processes in CXR. These processes are used to populate CXR s databases from information collected from different computer systems. CXR communicates with several different kinds of systems and there are several different data types in CXR s user databases. 9. Current implementation of the dbload processes The first generic of CXR had only one dbload process. Each new dbload process was created by cloning - making a copy of an existing dbload process and making it work for the new computer system. This method is an efficient way to develop the code for new dbload processes, but it causes problems later for fixing bugs. The dbload processes represent only about 6.8% of the total code in CXR (about 9000 lines of code), but these processes have accounted for 12% of the total CXR bug fixes. The z test can be used to test the significance of the variation of the proportion of bug fixes in the dbload processes from the proportion of total code that comprises the dbload processes. The z value is 4.50, so the variation is significant at the 99.99% level. In conclusion, the current CXR dbload processes are trouble. They have caused problems for the CXR developers because their structure is inflexible and error-prone. 10. New design for dbload process The new design for the CXR dbload processes has an object oriented structure. This structure was chosen for two reasons: - The parts of the code in the existing dbload processes that are exactly the same in several different processes can be factored out. This will decrease the size of the code and will reduce the amount of effort in fixing bugs in the dbload processes. - New computer system types and new data types will be added in the near future. In an object oriented structure, adding these new types will be much easier. The new design will have only one dbload process. The deferred binding of member functions will permit one dbload process to do the job of all eight dbload processes in the old design. Inheritance is used to specify the portions of the dbload process that can change for communicating with different computer systems. 11. Estimated code reduction in the new design The current dbload processes currently total 9000 source lines. The total code for the new design has been estimated at about 3500 source lines. The smaller size of this process, together with its improved 68

7 structure, will greatly reduce the maintenance problems for this area of the CXR system. The CXR team is planning to implement this design, so there will be verification of these claims in the near future. They also plan to support two new computer system types soon, so the extendibility of this design will be tested - it should only be necessary to write two new classes with no changes required to the main part of the dbload process. 12. Conclusions The object oriented parts of the CXR system have produced several maintenance benefits. - Software reuse has doubled (from lines to lines reused) as more of the system is built in an object oriented way. CXR is using more classes, and more of those classes are derived from existing classes. CXR has achieved about 34% reuse savings from writing and using its own class libraries, and it gets about 19% reuse savings in developing classes just by using inheritance rather than building each new class from scratch. New features are added to the object oriented sections with less effort and with fewer interface changes within the system. New features in the object oriented sections of CXR change the interface of functions only 41% of the time, while new features added to the structured design parts of CXR change the interface 74% of the time. Interface changes cause the development and testing of these changes to be more difficult. New feature development is a significant part of the maintenance process, usually about one-half of maintenance activity. - Accommodations to external change in CXR s object oriented modules cause significantly fewer source lines to be modified than for similar changes in CXR s structured design modules. In CXR s object oriented modules, accommodations to external change affect the same number of source lines as bug fixes, on the average. On the other hand, the external accommodations MRs in the structured design sections have caused significantly more source lines to be changed. The number of files modified per MR is greater over all of the object oriented sections of CXR than for the structured programming sections, but the number of code blocks changed is about constant. - Redesign of selected subsystems using the object oriented paradigm are expected to save in maintenance effort. Redesign and reimplementation of CXR s dbload process is expected to decrease the size of the subsystem (estimated reduction = 60%) and will provide an organized method to follow for extending the system to communicate with new systems. The CXR team looks forward to the benefits of these maintenance savings for years to come. REFERENCES 1. B. Lientz and E. Swanson, Software Maintenance Management, Addison-Wesley, C++ Libraries, Manuals and Tutorials, Release 2, Software Systems Department (59112), AT&T Bell Laboratories, Liberty Corner, NJ, William Havanas, CXR mr list, internal memorandum. 69