Defining metrics for software components Tullio Vernazza, Giampiero Granatella Dipartimento di Informatica, Sistemistica e Telematica Università degli Studi di Genova Giancarlo Succi§ Department of Electrical and Computer Engineering, The University of Alberta Luigi Benedicenti Faculty of Engineering, University of Regina Martin Mintchev Department of Electrical and Computer Engineering, University of Calgary Abstract As component oriented programming becomes more popular, the need emerges for the definition of a suitable set of metrics to describe the internal attributes of components. This paper presents a set of component metrics based on the Chidamber and Kemerer metrics suite (1994). The metrics is validated with the properties based approach by (Briand et al., 1996). An example of usage of this metrics is presented, with reference to the Java 2 Swing package. 1 Introduction In the recent years, the concept of component object programming has become popular. The concept of “component” spans several software entities including objects, functions, classes either individually or grouped together (Szyperski, 1998). As people develop components, there is a need for defining suitable metrics to measure such components. The goal of this work is on the definition and validation of metrics for components. In this paper we focus on measuring components as group of classes. It is common to deploy part of software systems as group of classes; typical examples are Java packages or C++ STL. In addition, most design patterns are defined as group of classes (Gamma et al., 1994). Therefore, a study of this metrics has the potential of capturing the most relevant internal properties of a large set of the components developed and deployed today. In this paper we focus on measuring components as group of classes. The Chidamber and Kemerer (CK) metrics suite is a “de-facto” standard for measuring properties of classes and objects. We base our work on an extension of such metrics. In
§
Address for correspondence: Giancarlo Succi, Department of Electrical and Computer Engineering, University of Alberta, 238 Civil / Electrical Building, Edmonton, Alberta, Canada T6G 2G7. E-mail:
[email protected]
1 T. Vernazza, G. Granatella, G. Succi, L. Benedicenti, M. Mintchev (July 2000) “Defining Metrics for Software Components.” Proceedings of the World Multiconference on Systemics, Cybernetics and Informatics, Vol XI, pag. 16-23, Orlando, Florida.
addition, (Briand et al., 1996) has set reference properties that size, length, complexity, coupling and cohesion measures must follow; the proposed metrics follows such properties. This article is organized as follows: Section 2 reviews the state of the art in metrics for objects and components. Section 3 introduces the new set of metrics for components. Section 4 validates this new set with the properties of (Briand et al., 1996). Section 5 shows an example of applying this suite of metrics to the design patterns of (Gamma et al., 1994) found in the Java 2 Swing package. Section 6 draws some conclusions. 2 State of the art The investigation on metrics for components, defined as group of classes, naturally starts from a study of the existing metrics for object oriented system in particular from (Chidamber and Kemerer, 1991), subsequently discussed and revised in (Chidamber and Kemerer, 1994; Chidamber et al., 1998). A summary of the proposed CK metrics suites follows, using the definitions of (Chidamber and Kemerer, 1994). · Weighted method per class (WMC). Weighted methods per class is the summation of the complexity of each method of the class. If we consider the complexity of the method as unity, then WMC is equal to the Number of Methods in a class (NOM) (Li and Henry, 1993). · Depth of inheritance tree (DIT). Depth of inheritance tree is the maximum length of the path from the class to the root of the hierarchical tree. · Number of children (NOC). Number of children is the number of immediate subclasses of a class. · Coupling between object classes (CBO). Coupling between object for a class is the count of other classes to which it is coupled. Two classes are coupled if one acts on attributes of the other. · Response for a class (RFC). Response for a class is the cardinality of the set of methods that can potentially be executed in response to a message received by an object of that class · Lack of cohesion in methods (LCOM). Lack of cohesion in methods is a measure of how poorly the methods and the variables are related in a class. Li and Henry examined five of the six metrics of Chidamber and Kemerer and found their usefulness to predict maintainability of projects (Li and Henry, 1993). Other Object Oriented metrics has been introduced; several taxonomies have been proposed starting with (Abreu and Carapuca, 1994). (Abreu and Carapuca, 1994) classifies objectoriented metrics by category (design, size, complexity, reuse productivity, and quality) and granularity (method, class, system). (Briand et al., 1999) summarizes different methods for measuring coupling and evaluates them and their influence. Studies have been done in determining properties to validate software metrics (Weyuker, 1988; Zuse, 1991; Briand et al., 1996). (Briand et al., 1996) defines a set of properties (from now on referred to as “BMB properties”) that all size, length, cohesion, coupling measures should obey. The BMB properties require Size measures to be non-negative, to have a meaningful null value, and to have additive property for disjoint modules. Length measures should be nonnegative, have null value if there are no elements in the system, non-increasing monotonicity 2
for connected components, a non-decreasing monotonicity for non-connected components. Finally, for a system composed by disjoint modules, the length should be the maximum length of those modules. Cohesion measures should be non-negative and normalized, with a null value if there are no internal relations, with a non-decreasing value if new internal relations are added and increasing value if we merge two unrelated modules. Coupling measures should be non-negative, with a null value if there are no relationships in the system, with a non-decreasing monotonicity if new relations are added, with a decreasing value if modules are merged, and finally disjoint modules have the property of additivity for a coupling measure. 3 Extensions of the CK suite to components We extend the CK metrics suite to components, considered as aggregation of classes. In the majority of cases our metrics are a synthesis of the measures of the classes based on mean, maximum, minimum, or sum of the measures obtained with the CK class metrics. We replace LCOM, since it does have a set of properties for (Briand et al., 1996). In the remainder of this section we consider dealing with a component K formed by m classes Ci, i Î [1..m], with ni methods Mij, j Î [1..ni]. Using the notation of (Briand et al., 1996) we have a system S composed by different classes, some of them are in the component K, the others are external. We also consider a set of relationships among those classes.
Figure 1The component K
3.1 Extensions for NOM: weighted classes per component and number of classes A component consists of a group of classes, so it is reasonable that the complexity of the various classes influence the complexity of the resulting component. If the classes are complex, then they are more difficult to understand and maintain, and consequently the component will be complex and difficult to maintain. Using NOM to measure the complexity of the classes, we define the weighted class per component (WCC) as: m
WCC = å NOM (C i ) i =1
3
If we consider the complexity of each single class as unity, we can define the complexity of the component K as the number of classes (NC).
NC = m
3.2 Extensions for DIT: maximum of the DIT and mean of unrelated trees (Li and Henry, 1993) have evidenced that higher values of DIT identify classes that are hard to maintain: the effort in maintaining group of classes can therefore be indicated by the values of DIT. In particular we initially consider both the highest value of DIT, MAXDIT, and the mean of DIT of unrelated trees (MUT). The definition of MAXDIT is straightforward: MAXDIT = max{DIT (C i )} Ci ÎK
Multiple independent class hierarchies can be presented in graph of classes. The mean of unrelated trees is the mean of the values of MAXDIT for each independent hierarchy. Formally, assume that K is partitioned in r unrelated components Ui..Ur, with: r
UU
i
=K
i =1
and Ui and Uj never sharing any superclass when i is different from j. r
å MAXDIT(U ) i
MUT =
i =1
r
3.3 Extensions for NOC: number of children for a component NOC is extended by counting the number of children of all the classes in the component; we call this metric number of children for a component (NOCC) m
NOCC = å NC (C i ) i =1
It appears that NOCC is an indicator of reuse inside the component. 3.4 Extensions for CBO: external CBO We define the level of coupling for a component: external CBO (EXTCBO) as the number of external classes coupled to it m
EXTCBO = å ei i =1
Where ei is the number of external classes coupled to the class Ci. Clearly EXTCBO evidences the level of dependency of K on external entities. 3.5 Extensions for RFC: response set for a component The response set of a component (RFCOM) is the number of all the methods in the member classes and the methods called by those classes. This value is the sum of the values of RFC for all the classes in the set m
RFCOM = å RFC (Ci ) i =1
4
3.6 Measuring component cohesion We have discarded LCOM since it is not possible to verify it with the BMB properties. Instead we propose to measure component cohesion, as the number of internal classes to which a class is coupled normalized with the number of the possible coupling relationship among the classes: m(m-1). m
CC = å
m
å h(C , C i
j
) / m × (m - 1)
i =1 j=1, j¹i
ì1 if C i and C j are coupled where h(C i , C j ) = í 0 otherwise î Notice that:
4 Validation of the extended metrics Now we validate the proposed component metrics using the BMB properties. (Briand et al., 1996) demonstrated that the WMC, NOC, RFC satisfied the properties of size, the DIT the properties of length, the CBO the properties of coupling. These proofs are the base of the following discussion. 4.1 Validation of the extensions of WMC The extensions of WMC are measures of size: we need to verify the properties of nonnegativity, null value, and module additivity. Weighted classes per component · Non-negativity. The WCC is the sum of non-negative numbers, so it cannot be negative. · Null value. If the WMC of the single classes is zero (there are no methods in the classes), the value of WCC is null. · Module additivity. Giving a component C formed by two single, non-overlapped components A and B, WCC(C)= WCC(A)+WCC(B). Number of classes · Non-negativity. In a component, we can have at less zero or more classes. Therefore, the NC is not negative. · Null value. If there are no classes in the component, the value of the NC is zero. · Module additivity. Giving a component C formed by two single, non-overlapped components A and B, NC(C)= NC(A)+NC(B). 4.2 Validation of the extensions of DIT The extensions of DIT are measures of length: we need to verify properties of non-negativity, null value, non-increasing monotonicity for connected components, non-decreasing monotonicity for non-connected components and disjoint modules.
5
Maximum of the DIT · Non-negativity. DIT is non-negative because it is the distance (the number of ancestors) from a leaf to the root. MAXDIT is the maximum value among positive numbers (DIT), therefore it cannot be negative. · Null value. If there are no hierarchical relations in the component, DIT of each class is zero and consequently MAXDIT is zero. · Non-increasing monotonicity for connected components. If new hierarchical relations are added to a connected component, DIT does not increase, because the longest path from a class to the root remain the same. Being the maximum of DIT also MAXDIT satisfies this property. · Non-decreasing monotonicity for non-connected components. If relationships, among elements of different modules, are added, DIT can only increase (finding a longer path) or remains the same. Therefore, MAXDIT will also only increase or remains the same. · Disjoint modules. This property is true by the definition of MAXDIT: maximum value of the DIT of the classes inside the component. Mean of unrelated trees · Non-negativity. The mean of positive numbers (as DIT is) is a positive number. · Null value. MUT is zero if the DITs of all classes inside the component are null. · Non-increasing monotonicity for connected components. Since the MAXDIT for all the unrelated trees does not increase also if we add relations to a connected component, the MUT does not increase. · Non-decreasing monotonicity for non-connected components. This property is not true for MUT because if we add new relations to unrelated modules, we modify the set of unrelated trees changing both the value and the number of the unrelated trees, and thus also the mean changes. · Disjoint Modules. It is false for the MUT because it is the mean of the MAXDIT of two disjoint modules and not the maximum value. 4.3 Validation of the extension of NOC The extension of NOC is a measure of size. Number of children for a component · Non-negativity. The NOCC is the sum of NOC (number of children of a class, zero or a positive number), so it cannot be negative. · Null value. If the NOC of the single classes is zero (the classes does not have children), the value of NOCC is null. · Module additivity. The module additivity is proven by the definition of NOCC, which is the sum of the NOC of the single classes inside a component. 4.4 Validation of the extension of CBO The extension of CBO is a measure of coupling: we need to verify the properties of nonnegativity, null value, monotonicity, merging of modules and disjoint module additivity. External CBO · Non-negativity. EXTCBO is the count of coupling relations with external classes, so it cannot be negative. · Null value. The EXTCBO is zero if there are no relations with external classes. · Monotonicity. If we add internal relations in a component, the EXTCBO will be the same, if we add relations to external classes it will increase. 6
·
·
Merging of modules. If we merge two modules, A and B, the EXTCBO of the component will be: EXTCBO (C) = EXTCBO (A)+EXTCBO (B)- (relation between A and B) All the four operands are positive numbers, so the coupling of a module, obtained by merging two modules, is not bigger than the sum of the couplings of the two original modules. Disjoint module additivity. If we take the same relation of the previous demonstration the least operator is equal to zero and therefore we have: EXTCBO (C) = EXTCBO (A)+EXTCBO (B)
4.5 Validation of the extension of RFC The extension of RFC is a measure of size. Response set for a component · Non-negativity. RFC is non-negative. The RFCOM is the sum of RFC, so it cannot be negative. · Null value. The value of RFCOM is zero if there are no methods inside the classes in our components. · Module additivity. Proven by definition of RFCOM that is the sum of the RFC of the single classes inside a component. 4.6 Validation of Component Cohesion Component cohesion is a measure of cohesion: we need to verify the properties of nonnegativity and normalization, null value, monotonicity, cohesive modules. Component cohesion · Non-negativity and normalization. CC cannot be negative because it is the sum of the number of internal classes to which a class is coupled. This value has a defined maximum equal to 1, reached when all the classes are coupled among them-selves. · Null value. CC is zero if the classes inside our component are not coupled. · Monotonicity. If we add internal relations inside a component, obviously the CC does not decrease, but it either increases or remains the same. · Cohesive modules. If two modules that do not have relations between them are merged, CC does not increase. In fact, the number of relations among the classes inside our component will be the same. 4.7 A metrics suite for components Table 1 contains a summary of the proposed component metrics and if they satisfy the appropriate BMB properties. A cell contains an X if the metric satisfy the property and an O if it does not satisfy the property; a cell is shaded if the property does not apply to the metrics.
7
Type of measure Non-negativity Null value Module additivity Non-decreasing monotonicity Non-increasing monotonicity Disjoint modules Merging of modules Monotonicity Cohesive modules
WCC Size X X X
NC Size X X X
MAXDIT Length X X
MUT Length X X
X
O
X
X
X
O
NOCC Size X X X
EXTCBO Coupling X X
RFCOM Size X X X
CC Cohesion X X
X X X
X = satisfies the property
X X
O = does not satisfy the property
Table 1. Metrics for components and BMB properties. Only the MUT does not satisfy the properties of (Briand et al., 1996) so we discard this metric from our suite. 5 Example of use of the proposed metrics suite As an example of use of the proposed metrics suite, we have applied it to the Gamma’s design patterns (Gamma et al., 1994). Figure 2 contains the definition of the abstract factory pattern. For each class the value of the CK metrics can be computed (Table 2).
8
Figure 2The structure of the Abstract Factory Class Abstract Factory Concrete Factory 1 Concrete Factory 2 Abstract ProductA ProductA2 ProductA1 Abstarct ProductB ProductB1 ProductB2
NOM
DIT
NOC
CBO
RFC
2
0
2
0
2
2
1
0
2
2
2
1
0
2
2
0
0
2
0
0
0 0 0
1 1 0
0 0 2
0 0 0
0 0 0
0 0
1 1
0 0
0 0
0 0
Table 2. CK metric suite applied on the Abstract Factory pattern The proposed metric suite allows an analysis of the patterns as a whole (Table 3). WCC is 6 because the abstract factory contains 6 methods. NC is 9: the number of classes in the pattern. MAXDIT is 1: the longest inheritance hierarchy in the component. NOCC is 6: the number of children in the component. No class is coupled with an external class, therefore EXTCBO is 0. RFCOM is 6: the number of possible messages of the component. CC is 0.056: the number of coupling relations inside the component. Table 3 contains the values of the proposed metrics for the patterns of (Gamma et al., 1994), the last column is the count of their occurrences in the Java 2 Swing package. The identification and the count of the patterns have been performed manually as part of a University graduate course. The façade pattern is not reported because it does not have a specific class structure.
9
Pattern Abstract Factory Builder Factory Method Prototype Singleton Adapter Bridge Composite Decorator FlyWeight Proxy Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor
Swing
WCC 6
NC 9
MAXDIT 1
Metrics NOCC 6
EXTCBO 0
RFCOM 6
CC 0.056
1
4 3
4 4
1 1
1 2
0 0
4 3
0.17 0.083
1 49
3 3 3 4 9 6 4 3 3
3 1 3 5 3 5 4 3 3
1 0 1 1 1 2 1 1 1
2 0 2 3 2 4 2 2 2
0 0 0 0 0 0 0 0 0
3 3 4 5 10 7 4 4 4
0.17 0 0 0.05 0.17 0.05 0.083 0.17 0.17
1 0 14 52 3 0 5 0 1
3 3 7 0 4 7 4 5 5
4 3 4 5 3 4 4 5 2
1 1 1 1 0 1 1 1 1
1 2 2 3 0 2 2 3 1
0 0 0 0 0 0 0 0 0
4 3 3 0 5 9 5 5 6
0.17 0.17 1 0.083 0.17 0.17 0.083 0.05 0
2 2 1 1 0 44 2 5 0
11
7
1
4
0
12
0.048 Total
0 184
Table 3. The component metric suite applied to the design patterns The value of EXTCBO is 0 for all the patterns. The ranges of MAXDIT, CC, and NOC are narrow: [0..2], [0..0.17], and [0..6] respectively. No significant linear relation has been identified between the proposed metrics and the number of uses of the design patterns. However, it is noticeable that the most used design patterns, the factory method, the bridge, and the observer, do not have extreme values for the metrics: WCC ranges from 3 to 7, NC from 4 to 5, MAXDIT from 0 to 1, NOCC from 2 to 3, RFCOM from 3 to 9, and CC from 0 to 0.17. On the contrary, it appears that when a pattern reaches extreme values of one or more metrics it is either not used or used only in very few cases. 6 Conclusion While components are becoming always more popular, almost no metrics have been proposed for components as such. In this paper, we have defined a set of component metrics based on the CK object oriented metrics suite, and validated it with the properties defined in (Briand et al., 1996). As a sample application, we have applied this set of metrics to the Gamma’s design patterns. This is clearly an initial work; more research is needed and empirical validation of the proposed metrics is required on industrial data, to determine the usefulness of such metrics to infer properties of the final systems based on the analysis of the components. 10
Acknowledgements We thank Frank Dong, Ali Hariri, Chethana Kuloor, Eric Liu, Ali Mohamed, Rob Morris, Paolo Predonzani, Romana Spasojevic and Raymond Wong for identifying the design pattern in the Java 2 Swing package. We thank also Eric Liu (again) and Jason Yip for reviewing this paper. This research has been partially supported by the European Union, the Canadian National Science and Engineering Council, the Government of Alberta, and the University of Calgary. References Abreu, F.B., R. Carapuca (1994) “Candidate Metrics for Object-Oriented Software within a Taxonomy Framework,” Journal of System Software, 26(1) Briand, L., J.W. Daly, J.K. Wust (1999) “A Unified Framework for Coupling Measurement in Object-Oriented Systems,” IEEE Transaction on Software Engineering, 25(1) Briand, L., S. Morasca, V. Basili (1996) “Property-based Software Engineering Measurement,” IEEE Transactions on Software Engineering, 22(1) Chidamber, S., D. Darcy, C. Kemerer (1998) “Managerial Use of Metrics for ObjectOriented Software: An Exploratory Analysis,” IEEE Transaction on Software Engineering, 24(8) Chidamber, S., C. Kemerer (1991) “Towards a metrics suite for object oriented design,” OOPSLA Chidamber, S., C. Kemerer (1994) “A Metric Suite for Object Oriented Design,” IEEE Transactions on Software Engineering, 20(6) Fenton, N.E., S.H. Pfleeger (1996) Software metrics a rigorous and practical approach, Thomson Computer Press Gamma, E., R. Helm, R. Johnson, J. Vlissidies (1994) Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing Halstead, M.H. (1977) Elements of Software Science, Elsevier Henry, S.M., W. Li (1993) “Object Oriented Metrics that Predict Maintainability,” Journal of System Software, 23(2) Hatton, L. (1997) “Reexamining the Fault Density-Component Size Connection,” IEEE Software, 14(2) McCabe, T. (1976) “A Complexity Measure,” IEEE Transaction on Software Engineering, 2(5) Szyperski, C. (1998) Component Software, Addison-Wesley Weyuker, E.J. (1988) “Evaluating Software Complexity Measure,” IEEE Transaction on Software Engineering, 14(9) Zuse, H. (1991) Software Complexity: Measure and Methods, de Gruyter
11
