826
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
Improving Cohesion Metrics for Classes by Considering Dependent Instance Variables Heung Seok Chae, Yong Rae Kwon, Member, IEEE Computer Society, and Doo Hwan Bae, Member, IEEE Abstract—The existing cohesion metrics for classes do not consider the characteristics of dependent instance variables that are commonly used in a class and, thus, do not properly reflect the cohesiveness of the class. This paper presents an approach for improving the cohesion metrics by considering the characteristics of the dependent instance variables in an object-oriented program. Index Terms—Cohesion, object-oriented design, metrics/measurement.
æ 1
INTRODUCTION
VOL. 30,
NO. 11,
NOVEMBER 2004
measurement of cohesion. A class has dependent instance variables whose values are computed from other instance variables in the class. Existing cohesion metrics neglected both the existence of dependent instance variables and the characteristics of dependent instance variables. In this paper, we present an approach to improving the existing cohesion metrics by considering the effects of the dependent instance variables. We explore how the characteristics of dependent instance variables affect cohesion and describe a method for identifying dependent instance variables in a class. We also demonstrate the importance of dependent instance variables by conducting a case study with a class library. The rest of this paper is organized as follows: Section 2 describes the problems with the existing cohesion metrics with respect to the dependent instance variables, and Section 3 proposes an approach to identifying the dependent instance variables. Section 4 describes a case study that was performed in order to show effects of dependent instance variables. Finally, conclusions and suggestions for future work are given in Section 5.
COHESION, originating in structured design [25], refers to the relatedness of the elements in a module. A highly cohesive module is one whose elements have tight relationships among themselves while providing a single functionality of the module. On the contrary, a low cohesive module has some elements that have little relation to others, which may indicate that the module possesses several unrelated functionalities. It is widely accepted that the higher the cohesion of a module is, the easier the module is to develop, maintain, and reuse. Also, there is empirical evidence that supports the importance of cohesion in structured design [10], [11]. Therefore, virtually every software engineering text describes high cohesion as a very desirable property of a module. Numerous cohesion metrics have been proposed for objectoriented modules [3], [5], [12], [13], [14], [18], [19], [22] and researchers have attempted to take the characteristics of methods into account in the definition of cohesion metrics. Distinguishing public methods from nonpublic methods, Bieman and Kang [3] proposed LCC (Loose Class Cohesion) and TCC (Tight Class Cohesion) only with public methods in a class. They also excluded constructors and destructors in order to remove the impacts of artificial connection by those methods. Briand et al. [5] mentioned that presence of access methods artificially decreased class cohesion, whereas constructors and destructors artificially increased class cohesion. In an effort to resolve such problems, Chae et al. [12] noted that special methods had no influence on class cohesion because those methods were designed to show a specific behavior, interacting inherently with only some of the instance variables for specific purposes. The works by Bieman and Kang, Briand et al., and Chae et al. are attempts to incorporate the characteristics of those kinds of methods into cohesion metrics. As they paid special attention to the characteristics of methods, we note that it is necessary to consider the characteristics of instance variables for proper
. H.S. Chae is with the Department of Computer Science and Engineering, Pusan National University, 30, Jangjeon-dong, Geumjeong-gu, Busan 609-735, Korea. E-mail:
[email protected]. . Y.R. Kwon and D.H. Bae are with the Division of Computer Science, Department of Electrical Engineering and Computer Science, Korea Advanced Institute of Science and Technology, 373-1, Guseong-dong, Yuseong-gu, Daejeon 305-701, Korea. E-mail: {kwon, bae}@selab.kaist.ac.kr Manuscript received 16 Mar. 2004; revised 23 Aug. 2004; accepted 25 Aug. 2004. Recommended for acceptance by B. Cheng. For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference IEEECS Log Number TSE-0045-0304. 0098-5589/04/$20.00 ß 2004 IEEE
Published by the IEEE Computer Society
2 2.1
COHESION METRICS AND DEPENDENT INSTANCE VARIABLES The Cohesion Metrics for Classes
As object-oriented methodology gains popularity in industrial and academic settings, research has been conducted on object-oriented cohesion metrics. Major existing cohesion metrics were reviewed in [5] and abbreviated definitions of those metrics are presented in Table 1. Existing cohesion metrics are classified into three categories according to the cohesion criterion adopted by its definition. The cohesion criterion indicates what contributes to the cohesiveness of a class. Briand et al. [5] summarized that the cohesion criteria adopted by the existing cohesion metrics are either instance variable usage or sharing of instance variables. The criterion of instance variable usage indicates that cohesion is proportional to the number of instance variables in a class that are referenced by methods in the class. LCOM5 and Coh fall into this category. All other metrics except CBMC adopt the criterion of sharing of instance variables; that is, the larger the number of method pairs of a class sharing instance variables is, the more cohesive the class is. Chae et al. [12] note that these two criteria lead to some inconsistency between the computed cohesion value and the intuitively expected value. In order to resolve the problems due to those criteria, they introduce member connectivity as a new criterion. According to the criterion of member connectivity, a class with the more strongly connected members is more cohesive. In this paper, discussion on effects of dependent instance variables is centered on the metrics in Table 1 because they have been widely accepted among the software engineering community; they have been used in numerous empirical studies for investigating relationship between metrics and quality factors such as development/maintenance effort [1], [8], [15], [20], [21], fault-proneness [2], [6], [7], [17], [22], and testability [9]. In addition, their use is gradually increasing in industry settings. This is manifested by the increasing number of industrial software tools, such as Together Control Center and Rational Rose, which provide automated computation of some metrics in Table 1. CBMC is included because it is one of most recently proposed cohesion metrics and has some peculiar properties that have not been found in other metrics. In addition, there are agreements on the point that CBMC can overcome limitations of the existing metrics [20], [21], [26].
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 30,
NO. 11,
NOVEMBER 2004
827
TABLE 1 The Major Cohesion Metrics
2.2
Dependent Instance Variables
Instance variables in a class capture the state information common to the objects instantiated from the class. In this paper, we classify instance variables into base instance variables and dependent instance variables. Dependent instance variables have their values computed from other instance variables. On the contrary, the values of base instance variables cannot be derived from other instance variables; their values can be assigned only by the execution of methods in the class. Thus, we can derive the values of the dependent instance variables from base instance variables and other dependent instance variables. In this respect, dependent instance variables are redundant because they add no semantic information. However, they are commonly used because they improve understandability and performance of an object-oriented program [24]. In addition, UML provides a notation for describing attributes that can be derived from others [4]. Consider class Employee in Fig. 1. Class Employee has seven instance variables, three of which are dependent instance variables. The value of instance variable gross can be derived from instance variables workDays and salaryRate. Similarly, the values of instance variables tax and net can be derived from instance variables gross and taxRate, and gross and tax, respectively. The dependency relation between the instance variables in class Employee is depicted in Fig. 2.
Note that a method has an implicit relationship with dependent instance variables along with base instance variables that can be explicitly accessed. In other words, by accessing a dependent variable, a method interacts implicitly with its base instance variables as well as the dependent variable. For example, by referencing the dependent instance variable gross, method getGrossðÞ also interacts implicitly with its base instance variables workDays and salaryRate because the value of gross depends on those of workDays and salaryRate. Similarly, when method getT axðÞ interacts with instance variable tax, getT axðÞ interacts not only with instance variable tax but also with the tax’s base instance variables gross and taxRate. Fig. 3 illustrates explicit and implicit interactions among the members of class Employee. A rectangle represents a method and an ellipse represents an instance variable. A solid edge between a method and an instance variable indicates that an explicit interaction exists between them because the method actually references the instance variable. A dotted edge represents an implicit interaction via dependency relation. As shown in Fig. 3, class Employee has 11 implicit interactions and 20 explicit interactions. We believe that, in addition to explicit interactions that can be directly identified in a source code, implicit interactions also contribute to the cohesiveness of a class and, thus, should be reflected in the definition of cohesion metrics. For instance, if method getGrossðÞ references the instance variable gross, method
828
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 30,
NO. 11,
NOVEMBER 2004
Fig. 2. Dependency between instance variables of class Employee.
methods getGrossðÞ and getNetðÞ seem to have no common instance variables with respect to explicit interactions. However, those methods indirectly share instance variables workDays, salaryRate, and gross. Existing cohesion metrics such as LCOM1, LCOM2, Co, LCC, and TCC do not include indirect sharing of instance variables, thus, leading to a lower cohesion value. In the case of LCOM3 and LCOM4, although they did not mean to include the effects of dependent instance variables, implicit interactions among instance variables are coincidentally reflected by their definitions. The connectivity factor of CBMC is defined as the ratio of the number of glue methods to the number of normal methods. Implicit interactions are not considered in computing glue methods. That is, a reference graph that is connected by implicit interactions is considered disjoint, which leads to a smaller cohesion value. Fig. 1. Class Employee.
getGrossðÞ has a hidden relation with workDays and salaryRate because gross is derived from workDays and salaryRate. Therefore, implicit interactions via dependencies between instance variables should be considered to more accurately evaluate the cohesiveness of a class. However, existing cohesion metrics have no notion of dependent instance variables and do not consider those implicit interactions via dependent instance variables either. Because they do not consider the relations that actually exist between members, they fail to properly evaluate the cohesiveness of a class, producing a cohesion value lower than expected. More specifically, metrics associated with the criterion of instance variable usage such as Coh and LCOM5 count explicit interactions but not implicit interactions. Note that method getT axðÞ has implicit interactions with workDays, salaryRate, and taxRate. However, because Coh and LCOM5 do not count those implicit interactions, their cohesion values are usually lower than anticipated. Similarly, the metrics associated with the criterion of sharing of instance variables such as LCOM1, LCOM2, LCOM3, LCOM4, Co, LCC, and TCC do not consider the method pairs with indirectly shared instance variables due to implicit interactions. For example,
Fig. 3. Interactions among members of class Employee.
3
CONSIDERATION OF DEPENDENT INSTANCE VARIABLES
To properly evaluate the cohesiveness of a class, dependent instance variables should be identified from the class, and implicit interactions via dependent instance variables should be considered in computing cohesion metrics. To evaluate the cohesiveness of a class considering dependent instance variables, we first identify a dependency relation between instance variables. When the value of one variable is at least partly defined by that of the other variable, a dependency relation between those two variables is said to exist. A dependency relation is identified by analyzing the implementation of each method in the class.
3.1
Intramethod Dependency Analysis
Definition 1. The dependency relation between variables in statement s of a method, denoted by V DS ðsÞ, is a set of pairs of variables and is defined as follows: V DS ðsÞ ¼ f< vi ; vj >j vi is a variable defined in s and vj is a variable used to define the variable vi in s. For example, consider class A shown in Fig. 4. Method Af1() has four assignment statements and a dependency relation occurs on each of them. That is, V DS ðs1 Þ ¼ f< v; av1 >g,
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 30,
NO. 11,
NOVEMBER 2004
829
Because of the assignment statement in method Bf1ðÞ, a dependency relation occurs between instance variable bv of instance b and cv1. Thus, instance b depends on cv1. Due to polymorphism and dynamic binding, a method invocation can be bound at runtime to a number of methods in an object-oriented program. In this paper, we do not address polymorphism because we cannot determine statically the method to which it will be bound. However, the method described here can be extended by analyzing all the methods that can be invoked in a polymorphic way. Let statement s be r ¼ t:cmða1 ; a2 ; . . . ; an Þ. Assume variable t is an object of class T and cmðf1 ; f2 ; . . . ; fn Þ is a prototype of the called method cm. Let RðcmÞ be the set of variables that appear on a return statement of method cm and R0 ðmÞ the set of variables that can affect the return value of method cm. That is, R0 ðmÞ ¼ RðmÞ [ fv j 9w 2 RðcmÞ < v; w > 2 V DM ðcmÞg We investigate three kinds of dependencies with respect to method invocations. .
A target object depends on actual arguments or vice versa. -
A target object depends on actual arguments. If a formal argument fi corresponding to actual argument ai is used to change any instance variable of target object t, then the target object t depends on the actual argument ai . 9v 2 V ðT Þ < v; fi > 2 V DM ðcmÞ ! V DS ðsÞ ¼ V DS ðsÞ [ f< t; ai >g:
-
For instance, for statement s1 of method CfðÞ, the value of bv of target object b is changed by actual argument cv1. Thus, V DS ðs1 Þ ¼ f< b; cv1 >g. An actual argument depends on a target object. If a formal argument fi corresponding to actual argument ai is modified by any instance variable of target object t, then the actual argument ai depends on the target object t. 9v 2 V ðT Þ < ai ; v > 2 V DM ðcmÞ ! V DS ðsÞ ¼ V DS ðsÞ [ f< ai ; t >g:
Fig. 4. Example classes for dependency analysis.
V DS ðs2 Þ ¼ f< av2; v >g, V DS ðs3 Þ ¼ f< av3; v >; < av3; x >g, and V DS ðs4 Þ ¼ f< av4; av2 >g. In the object-oriented literature, after a variable is declared, the variable can be explicitly initialized by means of an assignment statement. In this paper, a dependency relation is assumed to subsume initializations as well as assignments.
.
Definition 2. The dependency relation in method m, denoted by V DM ðmÞ, is defined to consist of all the dependency relations in method m.
9v 2 V ðT Þ; w 2 R0 ðcmÞ < v; w > 2 V DM ðcmÞ ! V DS ðsÞ ¼ V DS ðsÞ [ f< r; t >g:
V DM ðmÞ can be computed by transitively collecting V DS ðsÞ for all the statements in the method m. For example, dependency relations in method Af1ðÞ are V DM ðAf1ðÞÞ ¼f< v; av1 >; < av2; v >; < av2; av1 >; < av4; av2 >; < av4; v >; < av4; av1 >; < av3; v >; < av3; x >; < av3; av1 >g:
3.2
Intermethod Dependency Analysis
Invocations of other methods contribute to dependencies among variables in a class. For example, consider statement s1 of method CfðÞ in class C shown in Fig. 4. Instance variable cv1 in class C is passed as an argument to method Bf1ðÞ of instance b.
For example, for statement s2 of method CfðÞ, actual argument cv2 is changed by instance variable bv of target object b. Therefore, cv2 depends on b. Thus, V DS ðs2 Þ ¼ f< cv2; b >g. The return value of a called method is assigned. If any instance variable of target object t affects the return value of method cm and the return value is assigned to r, then r depends on t.
.
For instance, for statement s3 of method CfðÞ, instance variable bv of instance b affects the return value of method Bf3ðÞ and the return value of Bf3ðÞ is assigned to cv1. Thus, cv1 depends on b. V DS ðs3 Þ ¼ f< cv1; b >g. The return value affected by actual argument is assigned. If a formal argument fi corresponding to actual argument ai affects the return value of method cm and the return value is assigned to r, then r depends on ai 9w 2 R0 ðcmÞ < fi ; w > 2 V DM ðcmÞ ! V DS ðsÞ ¼ V DS ðsÞ [ f< r; ai >g: For instance, for statement s3 in method CfðÞ, actual argument cv0 affects the return value of method Bf3ðÞ and
830
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 30,
NO. 11,
NOVEMBER 2004
IV DðcÞ ¼ f< cv1; cv0 >; < cv2; b >; < cv2; cv1 >; < cv2; cv0 >g:
4
Fig. 5. The structure of the cohesion measurement tool.
the return value is assigned to cv1. Thus, cv1 depends on cv0. V DS ðs3 Þ ¼ f< cv1; b >; < cv1; cv0 >g.
3.3
Dependency Relations among Instance Variables
A dependency relation between instance variables in a class is computed by combining the dependencies between instance variables in each method of the class. In addition, the dependency relation has the following properties: . . .
The dependency relation is irreflexive. No instance variable depends upon itself. The dependency relation is asymmetric. If v depends on w, then w should not depend on v. The dependency relation is transitive. If v depends on w and w depends on x, then v depends on x.
Definition 3. Let V ðcÞ and MðcÞ be the sets of instance variables and methods in class c, respectively, then a dependency relation between instance variables in class c, denoted by IV DðcÞ, is defined as follows: IV DðcÞ ¼ f< vi ; vj > j < vi ; vj > 2 V DC ðcÞ ^ i 6¼ j ^ < vj ; vi > 2 = V DC ðcÞ ^ vi 2 V ðcÞ ^ vj 2 V ðcÞg [ V DM ðmÞ: where V DC ðcÞ ¼ m2MðcÞ
That is, the dependency relation is determined by removing reflexive and symmetric tuples. For instance, the dependency relation of class C is
A CASE STUDY
Through a case study with a C++ class library, we evaluate the importance of dependent instance variables on cohesion measurement of object-oriented programs and demonstrate how we can deal with dependent instance variables in computing cohesion values. We have also developed a cohesion measurement tool to automate the process of measuring both the original cohesion metrics and the improved cohesion metrics that incorporated the characteristics of dependent instance variables. Fig. 5 shows the overall structure of our cohesion measurement tool. The tool accepts a C++ source program and builds a class information DB with the information extracted from classes such as instance variables, methods, and interactions among them using GEN++ [16]. The tool then builds a data flow graph and computes various cohesion values, including the identification of dependent instance variables. We performed a case study on 102 classes included in the InterViews system [23], a C++ toolkit for X Windows developed at Stanford University, and provide a set of classes that define the behavior of graphical user interface objects such as windows, buttons, and menus. Fig. 6a shows the distribution of the number of instance variables in Interview classes. As it turns out, most of classes have a rather small number of instance variables. Fig. 6b shows the percentage of the dependent instance variables in classes in the InterViews. In Fig. 6b, the first bar indicates the percentage (10.6 percent) of dependent instance variables to all instance variables, the second bar the percentage (16.9 percent) of classes with dependent instance variables to all classes, and the third bar the percentage (59.0 percent) of dependent instance variables in classes with dependent instance variables. These data imply that dependent instance variables are frequently used in a real system. Fig. 7a shows how many classes are affected when we take dependent instance variables into account for each measure that we have studied. Except for LCOM3 and LCOM4, there exist one or more classes whose cohesion values are changed due to the treatment of dependent instance variables. Consideration of implicit interactions via dependent instance variables has no effect on LCOM3 and LCOM4. As we previously pointed out, although they did not mean to consider the characteristics of dependent instance variables, implicit interactions via dependent instance variables are coincidentally reflected by their definitions.
Fig. 6. Instance variables in Interview. (a) The distribution of instance variables. (b) The percentage of dependent instance variables.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 30,
NO. 11,
NOVEMBER 2004
831
Fig. 7. The impacts of dependent instance variables. (a) The percentage of changed classes. (b) The difference of cohesion LCOM1, LCOM2, LCOM3, and LCOM4. (c) The difference of cohesion Co, LCOM5, Coh, LCC, TCC, and CBMC.
TABLE 2 The Relative Increases of the Cohesion Measurement
Figs. 7b and 7c show the average differences of the cohesion values for classes that are affected by the dependent instance variables. All measures except LOCM1, LOCM2, LOCM3, and LOCM4 are normalized. To more effectively show the influence due to the dependent instance variables, we present separate charts for each category. Table 2 shows the relative increases in cohesion values for the cohesion measures. The relative increase in cohesion is defined as jCafter Cbefore j , where Cbefore is the cohesion value before the effects of Cbefore dependent instance variables are included and Cafter is the cohesion value after the effects of dependent instance variables are incorporated into the definition of cohesion. The higher the relative increase is, the larger the effects of the dependent instance variables to cohesion are. Case 1 describes the relative change in cohesion values for all classes in the InterViews. Except for CBMC, all the metrics have a small change because the percentage of classes whose cohesion values are affected by dependent instance variables is rather small (see Fig. 7a). Case 2 indicates the relative change in cohesion values of classes which have one or more dependent instance variables. Except for CBMC, the relative changes in Case 2 are larger than those in Case 1. This shows how many effects the dependent instance variables have on cohesion measurement since classes with no dependent instance variables are excluded. Case 3 indicates the relative change for classes whose cohesion values are affected by considering dependent instance variables. As seen in the table, there is a sizable increase in cohesion values.
The values for LCOM2 and LCC do not seem to be meaningful because, in the case of LCOM2 and LCC, a very small number of classes is affected by dependent instance variables. Nevertheless, along with Case 2, Case 3 shows that dependent instance variables can have significant effects on cohesion measurement. We have conducted a case study with only one class library. Through this case study, however, we found that dependent instance variables are commonly encountered and, thus, the characteristics of dependent instance variables can greatly affect the cohesion measurement.
5
CONCLUSION AND FUTURE WORKS
We investigated the effects of dependent instance variables on cohesion metrics for object-oriented programs and proposed an approach to identifying the dependency relations among instance variables. We also demonstrated the importance of our approach by performing a case study where many dependent instance variables were found and the cohesion values of many classes were clearly affected by considering dependent instance variables. As part of future work, it is necessary to investigate empirically whether improvements to cohesion metrics by considering dependent instance variables will result in improvements to the quality of classes. In addition, we will need to analyze the effects of dependent instance variables on coupling metrics.
ACKNOWLEDGMENTS
832
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
The authors would like to thank the anonymous referees for their valuable suggestions and comments. This research was supported by the University IT Research Center Project and the Pusan National University Research Grant, 2004.
REFERENCES [1] [2]
[3] [4] [5]
[6]
[7]
[8]
[9]
[10] [11]
[12]
[13]
[14] [15]
[16] [17]
[18] [19] [20]
[21]
[22] [23]
[24] [25] [26]
M. Alshayeb and W. Li, “An Empirical Validation of Object-Oriented Metrics in Two Different Iterative Software Processes,” IEEE Trans. Software Eng., vol. 29, no. 11, pp. 1043-1049, Nov. 2003. V.R. Basili, L.C. Briand, and W. Melo, “A Validation of Object Oriented Design Metrics as Quality Indicators,” IEEE Trans. Software Eng., vol. 22, no. 10, pp. 751-761, Oct. 1996. J.M. Bieman and B.-K. Kang, “Cohesion and Reuse in an Object-Oriented System,” Proc. Symp. Software Reusability, pp. 259-262, 1995. G. Booch et al., The Unified Modeling Language User Guide. Addison-Wesley, 1999. L.C. Briand, J.W. Daly, and J.K. Wu¨st, “A Unified Framework for Cohesion Measurement in Object-Oriented Systems,” Empirical Software Eng., vol. 1, no. 1, pp. 65-117, 1998. L.C. Briand, J.K. Wu¨st, S. Ikonomovski, and H. Lounis, “Investigation of Quality Factors in Object-Oriented Designs: An Industrial Case Study,” Proc. Int’l Conf. Software Eng., pp. 345-354, 1999. L.C. Briand, J.K. Wu¨st, J.W. Daly, and D.V. Porter, “Exploring the Relationship between Design Measures and Software Quality in ObjectOriented Systems,” J. Systems and Software, vol. 51, no. 3, pp. 245-273, 2000. L.C. Briand and J.K. Wu¨st, “Modeling Development Effort in ObjectOriented Systems Using Design Properties,” IEEE Trans. Software Eng., vol. 27, no. 11, pp. 963-986, Nov. 2001. M. Bruntink and A. Deursen, “Predicting Class Testability Using ObjectOriented Metrics,” Proc. Fourth Int’l Workshop Source Code Analysis and Manipulation, 2004. N.N. Card, G.T. Page, and F.E. McGarry, “Criteria for Software Modularization,” Proc. Eighth Int’t Conf. Software Eng., pp. 372-377, 1985. N.N. Card, V.E. Chruch, and W.W. Agresti, “An Empirical Study of Software Design Practices,” IEEE Trans. Software Eng., vol. 12, no. 2, pp. 264271, Feb. 1986. H.-S. Chae, Y.-R. Kwon, and D.-H. Bae, “A Cohesion Measure for ObjectOriented Classes,” Software Practice and Experience, vol. 30, no. 12, pp. 14051431, 2000. S.R. Chidamber and C.F. Kemerer, “Towards a Metrics Suite for ObjectOriented Design,” Proc. Sixth ACM Conf. Object-Oriented Systems, Languages and Applications, pp. 197-211, 1991. S.R. Chidamber and C.F. Kemerer, “A Metrics Suite for Object-Oriented Design,” IEEE Trans. Software Eng., vol. 20, no. 6, pp. 476-493, June 1994. S.R. Chidamber, D.P. Darcy, and C.F. Kemerer, “Managerial Use of Metrics for Object Oriented Software: An Explorary Analysis,” IEEE Trans. Software Eng., vol. 24, no. 8, pp. 629-639, Aug. 1998. P. Devanbu, “GENOA a Customizable, Language and Front-End Independent Code Analyzer,” Proc. Conf. Software Eng., pp. 307-317, 1992. K. El Emam, S. Benlarbi, N. Goel, and S.N. Rai, “The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics,” IEEE Trans. Software Eng., vol. 27, no. 7, pp. 630-650, July 2001. B. Henderson-Sellers, Software Metrics. Prentice Hall, 1996. M. Hitz and B. Montazeri, “Measuring Coupling and Cohesion in ObjectOriented Systems,” Proc. Symp. Applied Corporate Computing, 1995. H. Kabaili, R.K. Keller, F. Lustman, and G. Saint-Denis, “Class Cohesion Revisited: An Empirical Study on Industrial Systems,” Proc. Fourth Int’l ECOOP Workshop Quantitative Approaches in Object-Oriented Software Eng., pp. 29-38, 2000. H. Kabaili, R.K. Keller, and F. Lustman, “Cohesion as Changeability Indicator in Object-Oriented Systems,” Proc. Fifth European Conf. Software Maintenance and Reeng., 2001. W. Li and S. Henry, “Object-Oriented Metrics that Predict Maintainability,” J. Systems and Software, vol. 23, no. 2, pp. 111-122, 1993. M. Linton, P.R. Calder, and J.M. Vlissides, “InterViews: A C++ Graphical Interface Toolkit,” Technical Report CSL-TR-88-358, Stanford Univ., 1988, ftp://interviews.stanford.edu/pub. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, ObjectOriented Modeling and Design. Prentice Hall, 1991. W. Stevens, G. Myers, and L. Constantine, “Structured Design,” IBM Systems J., vol. 12, no. 2, 1974. R. Subramanyam and M.S. Krishnan, “Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implifications for Software Defects,” IEEE Trans. Software Eng., vol. 29, no. 4, pp. 297-310, Apr. 2003.
. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.
VOL. 30,
NO. 11,
NOVEMBER 2004
