Metrics to Study Symptoms of Bad Software Designs Kuljit Kaur Chahal, Hardeep Singh,

Department of Computer Science and Engineering, Guru Nanak dev University, Amritsar, India

<kk.gndu@gmail.com>

Abstract Design of a software product largely influences its quality. Good design is one of the pre-requisites of a high quality product. Me-trics are usually used to assess the quality of software designs. The metrics for object oriented design focus on design characteristics, such as abstraction, coupling, cohesion, inheritance, polymorphism and encapsulation and are applied at attribute, method, class, pack-age, file and systems levels. Design metrics help the software de-signers to understand the problem areas in a design and to develop prediction models. A number of studies have modeled relation-ships between object oriented metrics and reusability, defects and faults, maintainability, and effort, and cost savings. So design me-trics can give an early indication of goodness of design and thus of the software product developed using that design. If designers know symptoms of bad design then it is helpful for them to avoid the bad design. In this paper, we have explored some of the symp-toms of bad design and studied metric relationships which high-light these symptoms.

Introduction

In recent years, OO technologies have emerged as a dominant software engineering practice and are often heralded as the silver bullet for solving software problems. OO development has proved its value for systems that must be maintained and modified. As OO technologies have some new characteristics, such as abstraction, encapsulation, inheritance, polymorphism, information hiding and reuse, traditional software metrics do not readily lend themselves to the OO notions [3]. Therefore, new ways of measuring OO software are largely researched on.

A significant number of object oriented product metrics have been proposed in literature. Metrics proposed by Abreu [1], Chidamber and Kemerer [9], Briand et al [4], Li and Henry [13], Lorenz and Kidd [14], Bansiya [2] are some of the metric suites mostly refe-renced in research literature. These metrics measure internal prop-erties of an object oriented product such as abstraction, encapsulation, cohesion, coupling and inheritance. Metrics are defined for different levels of granularity like attribute, method, class, package, file and system.

It is believed that internal product metrics are not of any use unless they are not mapped to external properties of software. Several quality models are proposed which map internal metrics to the ex-ternal quality of the object oriented software such as fault prone-ness, reusability, maintainability, effort and cost [3, 5, 6, 7, 8, 13, 18, 19]. But in our opinion, it is also useful to study the inter-dependencies of internal metrics to know more about the internal structure of a software product. A class, as an element of an object oriented system has two properties, its size and level of cohesion. For a large size class, low level of cohesion is a symptom of bad design. High correlation in values of the metrics, measuring these two properties of a class, is not desired. We can explore the rela-

tionships in different metrics to know more about the internal structure of a software product.

Here we focus on the CK-Metric suite only. Briand has stressed that these metrics measure different properties of software product elements. So they should be all independent of each other. For different systems, the correlation matrix for these metrics has dif-ferent values. If there is no significant correlation level in the ma-trix for all the metrics, we interpret that all the metrics are measuring different properties of the system. But what if some of the cells in the matrix contain significant numbers? These numbers may be indicating some good or bad symptoms of system design. In this paper, we study the CK-metric suite to explore their inter-dependencies for a software product as indicators of bad software design. We have chosen the CK-Metric suite, developed by Chidamber and Kemerer [9]. Most commercial/research prototypes metrics collection tools collect these metrics [20, 21]. They have also been theoretically [9] as well as empirically validated [8]. Cross valida-tion studies of this metrics suite also exist [3, 10, 17, and 18].

The CK- Metric Suite:

The CK-Metrics Suite has 6 metrics, which measure different as-pects of an object oriented system such as size, coupling, cohesion and inheritance [9]. A brief discussion is as follows:

1. Weighted Methods per Class (WMC)—Weighted Methods per Class is the count of methods in a class. The complexity of a class is the sum of the complexities of all the methods available in class. The larger is the number of methods in a class, the greater is the potential impact on children, since children will inherit all the me-thods defined in the class. Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse.

2. Depth of Inheritance Tree (DIT) - The Depth of Inheritance Tree metric is defined as the length of the longest path from the class to the root in the inheritance hierarchy. The deeper a class is in the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior. Deeper trees constitute greater design complexity, since more methods and classes are involved. However, the deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods.

3. Number of Children (N0C)-The number of children is the num-ber of immediate subclasses subordinate to a class in the hierarchy. This metric measures the scope of the influence of a class on its subclasses due to inheritance. The greater the number of children, the greater the likelihood of improper abstraction of the parent and

SIGSOFT Software Engineering Notes Page 1 January 2009 Volume 34 Number 1

DOI: 10.1145/1457516.1457522 http://doi.acm.org/10.1145/1457516.1457522

may be a case of misuse of sub classing. A class with large number of children requires more testing effort.

4. Response For a Class (RFC)-This metric counts the set of me-thods that can potentially be executed in response to a message received by an object of the current class. The larger the number of methods that can be invoked from a class through messages, the greater the complexity of the class. If a large number of methods can be invoked in response to a message, the testing and debugging of the class becomes complicated.

5. Coupling Between Objects (CBO)-This metric is a count of the number of other classes to which the current class is coupled. Two classes are coupled when the methods of one class use methods or attributes of another class. Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application. The larger the number of couples, the higher the sensi-tivity to changes in other parts of the design, and therefore main-tenance is more difficult. A measure of coupling is useful to determine how complex the testing of various parts of a design is likely to be. Higher the inter- class coupling, more rigorous the testing needs to be.

6. Lack of Cohesion of Methods (LC0M)-The cohesion of a class is characterized by how closely the local elements (methods and attributes) of a class are related to each other. Lack of Cohe-sion (LCOM) metric measures the dissimilarity of methods in a class based on their usage of class attributes. If two methods oper-ate on different sets of data, they are not assumed to be related. Lack of cohesion in a class indicates that responsibilities are not assigned properly to the classes. Classes with low cohesion could be subdivided into two or more subclasses with increased cohe-sion. High cohesion implies simplicity and high reusability.

Intuitive notions about metrics It is desired that the set of metrics selected for measuring a soft-ware product should be orthogonal. All the metrics in the set should measure different properties of the design element of the product. In the CK-Metric set, WMC measures size of a class and LCOM measures level of cohesion in a class. But intuitively, these two properties of a class are interrelated. For a large size class, low level of cohesion is a symptom of bad design. In this way, we can explore the relationships in different metrics to know more about the internal structure of a software product. One of the principles of good design is “high cohesion, Low coupl-ing”. If elements of a design are highly cohesive, it may not imply that they are loosely coupled as well. Both the aspects need to be measured separately. But negative correlation in these measures will indicate goodness of design. An improvement in the level of cohesion of elements of a design should correspond to a reduced number of inter-element couplings. As a cohesive component is self-sufficient, and so is less dependent on other elements to fulfill its responsibilities. Consider a class in an object oriented design, which has low level of cohesion and is highly coupled with other classes in the design. In order to make it more reusable, not only its cohesion has to be improved but its coupling with other classes has

to be reduced as well. In an object oriented system, a study of cor-relation in coupling and cohesion metrics can indicate the level of reusability of classes. High levels of negative correlation (low co-hesion, high coupling) in these two metrics indicate that classes are not reusable in other applications. No doubt, correlation analysis is not in itself sufficient to provide all details. We have to depend upon other statistical methods for complete analysis of the design. But it can serve as a complementary technique. It gives an over-view of the goodness of a design. So a study of the correlations of metrics can give some indications of bad symptoms of designs. Here we discuss some intuitive no-tions about the metrics present in the CK-metric suite. In the next section, we explore the design of a third party component by mea-suring the correlations of different metrics. Table 1 lists some of the intuitive notions about the properties of a design, and the me-trics measuring these properties. Last column of the table gives the type of correlation in the metric values that indicates bad design. For example, in the second row, a positive (+ve) correlation in DIT and LCOM is not desired. The classes deep in the hierarchy are more specialized, so should be more cohesive. If this is not so, we need to relook into the design.

S. No. Intuitive Notion Metrics

Type of correlation, indicating symptoms of bad de-

sign

1. Large is the size of a class, less will be the cohesion.

WMC, LCOM +ve

2.

Classes deep in the hierarchy are specialized, doing only one task at a time, so cohesion is more.

DIT, LCOM +ve

3. Keeping in mind first two hypo-theses, classes deep in hierarchy are of small size.

WMC, DIT +ve

4.

larger is the size of a class, more responsibilities, more will be the references from other classes.

WMC, CBO, & RFC

+ve

5. Number of children is more near the top of hierarchy.

NOC, DIT -ve

6.

Large number of children im-plies that class caters to more diversified requirements so cohesion will be low.

NOC, LCOM +ve

Table 1: Some intuitive notions about the properties of an object oriented design. Evaluating a software design using CK-Metric Suite The Ck-Metric suit [9] was applied to a software product designed using object oriented approach. The figures in table 2 show that there is no significant relationship of DIT with any of the other metrics; same is the case for NOC. Significant correlation values are shown in bold.

SIGSOFT Software Engineering Notes Page 2 January 2009 Volume 34 Number 1

DOI: 10.1145/1457516.1457522 http://doi.acm.org/10.1145/1457516.1457522

Table 2 Pearson’s correlation coefficients for an object oriented design.

Correlation in WMC and LCOM indicates positive relationship, which says that for large sized classes, level of cohesion is low. This can be interpreted as that responsibilities are not properly distributed in the classes. WMC and RFC show a positive significant trend, which indicates that classes which are big in size are having higher number of me-thod calls. This further indicates that some classes have been given higher responsibility than others in the system. This is further supported by the fact that LCOM and RFC are hav-ing positive trend, so classes with low levels of cohesion are de-pendent upon other classes for method execution. With reference to table 1, symptoms of bad design mentioned at serial no 1and 4 hold true. Evaluating a good OO design using CK-Metric suite In order to answer some intuitive questions regarding the design of an object oriented system, the CK-metrics suite was applied to a case study, used in a book on Object Oriented analysis and design to teach students principals of good design. The results are given in table 3.

WMC DIT NOC RFC LCOM CBO WMC 1.000 DIT -0.034 1.000 NOC -0.160 -0.326 1.000

RFC -0.133 -0.166 0.406 1.000 LCOM -0.263 0.373 -0.014 0.097 1.000

CBO 0.887 -0.303 0.109 0.155 -0.286 1.000 Table 3: Pearson’s correlation coefficients for a good object oriented design No significant correlation is found except in WMC and CBO. A positive strong correlation between the two indicates that as size increases, coupling of the class with other classes also increase. If we consider the correlation coefficients from 0.3 to 0.5 (and similarly negative) as moderate ones, then we can observe some more values from this table. NOC and DIT are negatively corre-lated. No doubt the relationship is not that strong, but the trend shows that as level of inheritance increases, number of children

that a class decreases. This indicates that classes deep in the hie-rarchy have less number of children, which is intuitively true as well. Classes at the deeper levels of hierarchy become more specia-lized, so less number of children. So a bad symptom listed at sr. no. 5 in table 1 does not hold true for this good design. DIT is positively related to LCOM, which means as DIT increases, Lack of Cohesion in the methods of a class increases. This relation should be otherwise positive, because as the class becomes specia-lized (with higher value of DIT), Cohesion should increase. DIT is negatively related to CBO, which means that as Depth of the class in the hierarchy increases, level of the coupling decreases i.e. classes at or near the leaf nodes are more self sufficient as they are specialized. NOC and RFC show positive correlation, i.e. classes with higher values of NOC, (high in the hierarchy) has more number of me-thods called from other classes. Such classes are shown to have higher levels of coupling as well.

So with reference to table 1, two symptoms of bad design (Sr. no. 2 &4) hold true.

Related Work

Design flaws are the deviations of a design from the good design principles. More are the design flaws in a design, less maintainable the design is. Some notable design flaws are God Class, God me-thod [15], refused bequest, feature envy and Shotgun surgery [11] etc. Fowler refers to them as bad smells [15]. Lanza and Marinescu call them design disharmonies [12].

Salahie et al [16] have mapped these design flaws to class proper-ties such as complexity, coupling and cohesion by defining rules like – If (class X has high Inter-Class Complexity) and (class X has high Coupling) then (class X probably has Shotgun Surgery). Similarly Lanza and Marinescu [12] present a detection strategy based approach to identify design disharmonies. Our approach is a very basic one. We consider only the intuitive notions about the class properties. Correlation analysis of metrics can indicate the severity of design flaws. For example positive correlation in class complexity and coupling (WMC & CBO) implies that a large number of classes may be suffering from Shotgun Strategy. Conclusion Several studies relate internal product related metrics of object oriented designs with the external quality attributes of the corres-ponding software products. Correlations in the internal metrics of an object oriented design can also give some indications about its good/bad features. In this paper some of the symptoms of a bad design are outlined and then the correlations of the metrics are observed. Such observations in the early phases can give some indications of bad design. The designers can use this knowledge to factor the design and organize the design elements in a better way.

WMC DIT NOC RFC LCOM CBO

WMC 1.000

DIT 0.089 1.000

NOC 0 -0.05 1.000

RFC 0.851 0.180 0.007 1.000

LCOM 0.617 0.021 0.035 0.575 1.000

CBO 0.612 0.210 -0.042 0.780 0.110 1.000

SIGSOFT Software Engineering Notes Page 3 January 2009 Volume 34 Number 1

DOI: 10.1145/1457516.1457522 http://doi.acm.org/10.1145/1457516.1457522

This activity can be repeated till the design is not free from these bad symptoms. In future we intend to prepare a more complete list of symptoms of bad designs. References

[1] Abreu, F. B., The MOOD Metrics Set, Proc. ECOOP'95 Workshop on Metrics, 1995.

[2] Bansiya J. and Davis. C.G., A Hierarchical Model for Object-Oriented Design Quality Assessment, IEEE Transactions on Software Engineering, 2002.

[3] Basili, V., Briand, L., Melo, W., A Validation of Object Oriented Design Metrics as Quality Indicators, IEEE Transac-tions on Software Engineering, vol. 22, pp. 751- 761, 1996.

[4] Briand, L., Daly, J., and Wuest, J., A Unified Framework for Coupling Measurement in Object-Oriented Systems. IEEE Transactions on Software Engineering, 25(1), 1999.

[5] Briand, L.C. Melo, W.L., Wust, J., Assessing the Applicability of Fault Proneness Models Across Object-Oriented Software Projects, IEEE transactions on Software Engineering, vol. 28, no. 7, 2002.

[6] Briand, L.C., Wust, J., The Impact of Design Properties on Development Cost in Object- Oriented Systems, Proc. 7th Int’l Software Metrics Symposium (METRICS 01), IEEE CS Press, 2001.

[7] Briand, L., C., Wuest, J., Daly, J., and Porter, V., Exploring the Relationships Between Design Measures and Software Quality in Object Oriented Systems. Journal of Systems and Software, 51, 2000.

[8] Chidamber, S., R., Darcy, D., and Kemerer, C.F., Managerial Use of Metrics for Object-Oriented Software: An Exploratory Analysis. IEEE Transactions on Software Engineering, 24(8), 1998.

[9] Chidamber, S. R., Kemerer, C. F., A Metrics Suite for Object Oriented Design, IEEE Transactions on Software Engineer-ing, vol. 20, 6, 1994.

[10] El-Emam, K., Benlarbi, S., Goel, N., and Rai, S., A Validation of Object- Oriented Metrics, NRC/ERB 1063, National Re-search Council of Canada, 1999.

[11] Fowler, M., Beck, K., Brant, J., Opdyke, W., and Roberts. D., Refactoring: Improving the Design of Existing Code, Ad-dison-Wesley, 1999.

[12] Lanza, M., Marinescu, R., Object Oriented Metrics in Prac-tice-Using Software metrics to Characterize, Evaluate, and Improve the Design of Object Oriented Systems, Springer, 2006.

[13] Li, W., Henry, S. Object-Oriented Metrics that Predict Main-tainability, Journal of Systems and Software, 23,1993.

[14] Lorenz, M., Kidd, J., Object-Oriented Software Metrics, Pren-tice- Hall, 1994.

[15] Riel, A. J., Object-Oriented Design Heuristics, Addison-Wesley, 1996.

[16] Salehie, M., Li, S., Tahvildari L., A Metric-Based Heuristic Framework to Detect Object-Oriented Design Flaws, in Pro-ceedings of the 14th IEEE International Conference on Pro-gram Comprehension (ICPC’06), 2006.

[17] Sharma, N., Joshi, P., Joshi, R. K., Applicability of Weyu-ker’s property 9 to Object Oriented Metrics, IEEE Transac-tions on Software Engineering, Vol. 32, No 3, 2006.

[18] Subramanyam, R., Krishnan, M.S., Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Impli-cations for Software Defects, IEEE Trans. Software Eng., vol. 29, no. 4, 2003.

[19] Zhou, Y., Leung, H., Empirical Analysis of OO Design Me-trics for Predicting High and Low Severity Faults, IEEE Transactions on Software Engineering, vol. 32, No. 10, Oc-tober, 2006.

[20] www.powersoftware.com [21] www.mccabe.com

SIGSOFT Software Engineering Notes Page 4 January 2009 Volume 34 Number 1

DOI: 10.1145/1457516.1457522 http://doi.acm.org/10.1145/1457516.1457522