parison to changes in size from JFreeChart 0.9.20 to JFreeChart 1.0.2 rele .....
classes assigned to a package can help us to know the distributio .... Page 14 ...
Chapter 4: Results and Analysis 4.1. Introduction A reusable component once developed can be used several times in different applications. It is tested before every use and this repeated testing removes defects, and increases (re)user’s confidence in the quality of the software component (Almeida et al., 2007). For a reusable component, quality of the component is expected to improve as it matures. However, it is also believed that the quality of a program degrades if it is not managed in successive version releases (Xie et al., 2009). In this research, an attempt has been made to identify metrics trends in successive evolutions of a reusable component in order to understand the trends in its design quality1. The main objectives of this study are: 1. To investigate design of an evolving software component, JFreeChart, with the help of metric trends. 2. To study the extent to which the OO concepts are followed by comparing metric values obtained for the software component with the metrics thresholds. 3. To test the hypothesis that during the maintenance activity: • Added classes have better properties (size, coupling, cohesion etc.) than removed classes. • Unchanged classes have better properties than changed classes. • Maintenance activity takes place only at shallow levels of hierarchy. • Maintenance activity results in extensive modifications in the organization of the inheritance hierarchy.
4.2 The Case Study This study is based on the data from a large open source project available at one of the largest storehouses of open source projects www.sourceforge.net. The software under study is a charting library, known as JFreeChart that developers can use to display professional quality charts in their applications. It is a class library that can be included in an application, and is not an end application in itself. David Gilbert started the JFreeChart project 9 years back in 2000. It is an open source reusable software component available under the terms of GNU Lesser General Public License (LGPL). First release of this reusable software component was available in November, 2001. At present several open source as well as commercial projects use this Software component. As claimed on its 1
Kuljit Kaur, Hardeep Singh, Evaluating an Evolving Software Component: Case of Internal Design, ACM SIGSOFT Software Engineering Notes, Vol. 34, Issue 4, July, 2009.
99
homepage http://www.jfree.org/jfreechart/index.html, http://www.jfree.org/jfreechart/index.html, it is being used in approximately 50,000 to 60,000 applications applications. This research studies over 43 versions of thi this project released in the time period from 2000 to 2008. 2008 Some of the releases are closely related sub releases, so treated as one release. Every release involves corrective as well enhancement related changes. The information regarding JFreeChart’s release history, bug reports and feature requests is presented in Table 4.1.. A diagrammatical description of the the same information is given in Figure 4.1 for easy analysis. Bug reports information is taken year wise as version wise information was not available. Table 4.1: General Information nformation for the Software Component. Year
-umber of Versions
Bug Reports
Feature Requests
2001
2
-
-
2002
11
71
44
2003
11
219
92
2004
7
100
82
2005
5
164
38
2006
3
118
22
2007
4
111
23
2008
-
79
17
250
Values
200 150 100 50 0 2001
2002
2003
Versions released
2004
2005
Time
Bug Reports
2006
2007
2008
Feature Requests
Fig.4.1: Year wise detail of version releases, bug reports and feature requests
It could be observed that new versions of the software component were released more frequently in the initial years, notably in the years 2002 2002-2004. 2004. Number of feature requests is also high during uring this time period. So in the beginning, new versions were released to incorporate the feature requests from the users and also to remove the defects reported. 100
Year 2005 onwards, requests for new features started going down and down. This may be interpreted as that users are satisfied with the functionality offered, or the software component in its present form is complete enough to support requirements of different users. At the same time, number of bugs reported is following a downward trend after ye year 2005. Reduction or absence of bugs is also related to increasing software quality (Murgia et al., 2009).. A decreasing number of feature requests and bug reports support the fact that quality of this popular software component has improved overtime. As evident from F Figure 4.2, the component does not display stable evolution. It shows unstable behaviour following the release JFreeChart 0.9.20. Size (measured in number of classes) changes considerably in the next 4 releases. However, However JFreeChart 1.0.1 release se is claimed to be the first stable release of the software component. Prior to JFreeChart 0.9.20 release, the largest increase in size is recorded corresponding to JFreeChart releases 0.9.6 to 0.9.7. The next larger increase corresponds to JFreeChart 0.9.2 0.9.2 to 0.9.3. But these changes are very small in comparison to changes in size from JFreeChart 0.9.20 to JFreeChart 1.0.2 releases (Figure 4.3). The peaks and troughs in the growth plot indicate feedback driven and controlled growth of the software component. component. The facts regarding the feature requests and bug-fixes (Table able 4.1) also support feedback driven growth in the initial years. The number of feature requests grows consistently for the releases in first two years, after that it declines. However bug fix requests increase with a sharp decline in 2004, and again increase in 2005 with a downward trend after that. JFreeChart 0.9.21 was the last version released in 2004.
Fig.4.2: 4.2: Growth Trend in Succ Successive releases of JFreeChart (measured in number of classes). c
A lot of maintenance activity happens in the next 4 versions released after JFreeChart 0.9.21. Turbulence in growth pattern can be seen partially due to negative feedback (increasing bug reports) and partially due to the developers’ effort to control tthe growth. 101
This seems to be the version after which the developers have tried to control the growth of the software.
Fig.4.3:: Increase/D Increase/Decrease in Number of Classes across Different Versions V
4.3 Metrics Analysis This research analyzes metrics etrics at three levelslevels System, Package and Class level.
4.3.1 System Level Metrics System level metrics are the metrics which measure the properties of a system at the highest level of abstraction. In this category, category this study includes metrics from the MOOD metric set (Abreu et al., 1996). 1996) This set has metrics to measure the basic properties of an object oriented design such as encapsulation, inheritance, polymorphism, and coupling. It is believed that these mechanisms, if incorporated in the design of a software softw product, help to make it easy to reuse and maintain (Rumbaugh et al., 2002).. But use of these features in a design depends upon the abilities of its designer. It is important to correlate improvements in software quality with the use of these mechanisms. System ystem level metrics for different versions of the software component were collected. Trends in the metric ric values are discussed next: 1. Method Hiding Factor (MHF) ( and Attribute Hiding Factor (AHF)) MHF and AHF represent average amount of class members (attributes or methods) hidden from other classes in a system. If all members of all the classes are hidden, then MHF and AHF both are 100% for the system. But this could not be possible possible practically. A class cannot exist in isolation in a system. It has to communicate with other classes to support the functionality of the system. Itt has to declare some of its methods as public. Therefore AHF may attain value 100% (and it is ideal too) too), but MHF should not. Number of visible methods of a class indicates its functionality. Larger is the value, more will be the functionality. High values of MHF indicate very less functionality. On the other hand, if all 102
members of all the classes are public, then AHF and MHF both are 0% for the system. This is also an alarming situation. A large number of public members of classes increase the probability of errors in a system. An acceptable range of 8% to 25% is suggested for MHF1. In another study of MOOD metrics on 9 commercial projects, MHF takes values in this range (Harrison et al., 1998a).
Fig.4.4: Method Hiding Factor (MHF) Metric Trend It could be observed from Figure 4.4, that the method hiding factor (MHF) metric remains within the prescribed limits for all the releases of the software component. MHF values in the lower range may be due to the fact that a proper top down decomposition process has not been followed for implementing abstractions in the system. On the other hand in Figure 4.5, attribute hiding factor (AHF) was initially low but it has improved over time. AHF is close to the optimal value. So MHF and AHF both show positive trends for this software component. It can be said that the design of the software component adheres to the concept of information hiding.
Fig.4.5: Attribute Hiding Factor (AHF) Metric Trend 2. Method Inheritance Factor (MIF) and Attribute Inheritance factor (AIF) MIF and AIF measure the extent to which individual classes of a system inherit properties from their respective base classes. MIF (AIF) is the ratio of the sum of inherited methods 1
http://www.aivosto.com/project/help/pm-oo-mood.html#abreumelo
103
(attributes) in all classes of a system to the total number of available methods (attributes) in all the classes. Systems in which classes inherit a large number of properties have large values of MIF/AIF.
Fig.4.6: Attribute Inheritance Factor and Method Inheritance Factor Metrics Trends All the releases show sufficient amount of inheritance. In Figure 4.6, MIF takes values in the range 80% to 95%, and AIF varies from 37% to 75%. These high values indicate satisfactory use of method inheritance. However in recent versions, there is a significant reduction in values of AIF with a very sharp decline from version JFreeChart 0.9.20 to JFreeChart 0.9.21. It may be due to increase in average class size as well as the number of classes of the software component over the period of time. As the denominator in case of AIF (MIF) metric is the sum of attributes (methods) of all classes in a system, increase in the value of the denominator may have resulted in decreasing trend for the metric values. It may be noted that at class level, the metrics related to method inheritance and attribute inheritance show an upward trend towards the latest versions (Figures 4. 25 and 4.52). However, on average number of inherited attributes has been very less in comparison to number of inherited methods. Probably due to this, decline in values of AIF is sharper in comparison to MIF. 3. Polymorphism Factor (PF) Polymorphism means having the ability to take several forms. For object-oriented systems, polymorphism allows the implementation of a given operation to be dependent on the object that contains the operation. An operation can be implemented in different ways in different classes. Classes with polymorphic operations are easier to extend and modify. The polymorphism factor (PF) metric is defined as the ratio of the actual number of different polymorphic situations to the maximum number of possible distinct polymorphic situations for all classes in a system. 104
In successive versions of this software component, PF takes values from 4% to 10%. Decreasing values of PF show less use of dynamic binding. Figure 4.6 shows that MIF is very high, i.e. there is considerable use of method inheritance. But decreasing values of PF in Figure 4.7 indicate that inherited methods are not extensively redefined in the subclasses. It is not desirable to redefine a large number of inherited methods as it indicates that hierarchy is created out of convenience rather than a natural one. Moreover the exact behaviour of a program in this regard can be studied with the help of dynamic metrics (Yacoub et al., 1999).
Fig.4.7: Polymorphism Factor (PF) Metric Trend 4. Coupling Factor (CF) Two or more classes are said to be coupled if they exchange messages or have other kind of relationships such as inheritance, aggregation, or association. More couplings in classes means that classes are more inter-dependent, difficult to understand and therefore harder to change and repair. Coupling factor is the ratio of actual number of couplings to the maximum possible pair wise couplings in a system. It does not include inheritance based class relationships. Metric value for the successive releases has decreased gradually except one peak that too in the second release only (Figure 4.8). CF took value 2 in JFreeChart version 0.9.4 and remained at that level for long time. After version JFreeChart 0.9.16, value of the metric CF is further reduced to 1 and has remained there till JFreeChart 1.0.11. Low values of CF indicate that classes communicate less with other classes which are not in the same
105
Fig Fig.4.8: Coupling Factor (CF) Metric Trend inheritance hierarchy (as CF does not include inheritance based coupling) coupling). Excessive coupling oupling between classes across the inheritance hierarchies does not indicate a good design as it is difficult to understand and modify for future extensions.
4.3.2 Package Level Metrics In object oriented nted terminology, a package is a collection of classes. Martin (2003) defined some metrics to evaluate design of packages. This section analyzes the metric results and interprets the values to discuss the trends in package design quality1. 1. Relation Cohesion Figure 4.9 presents average relation cohesion in packages of the software component across its different releases. Metric values have improved over the passage of time. As classes inside a package should be strongly related, the cohesion should be high. On the other hand, too high values may indicate over coupling. A good range for relation cohesion is 1.5 to 4.02. Assemblies where relation cohesion is 4.0 might be problem problematic. As per this rule of thumb in this component all releases, except 0.9.21, are problematic.
Figg.4.9: Relation Cohesion Metric Trend 1
Kuljit Kaur, Hardeep Singh,Package Package Metrics and Reusable Software Components – An Empirical Study, Study Proceedings of the IEEE International Advanced Computing Conference (IACC’09) , Patiala, India, March, 2009. 2 www.ndepend.com/metrics.aspx
106
2. Instability The instability metric is a normalized metric which combines efferent coupling with afferent coupling and gives instability as ratio of efferent coupling to sum of efferent coupling and afferent coupling. The metric range for this component varies from 0.7 to 0.8 with a few exceptions (Figure (Fig 4.10). This indicates that on average a large number of classes inside a package are dependent upon classes outside the package. As the component evolves, average instability of the packages remains high. It indicates that outside changes will affect the internal design of an average package. Instability measured alone cannot give some useful hints; it should be studied along with the abstractness metric discussed next.
Fig Fig.4.10: Instability Metric Trend 3. Abstractness Instability of packages in all versions of this component has been high throughout. However, at the same time abstraction level of packages has decreased gradually (see Figure 4.11).. It indicates that after several extensions/modifications extensions/modifications, the packages have become more concrete as perhaps more number of concrete classes and less number of abstract
classes
have
been
added
to
the
packages.
Fig.4.11: Average Abstraction Level of Packages. 107
Packages were having sufficient levels of abstraction abstraction in the beginning, which was useful to extend them to support future requirements. Now the component has become general enough to support the maximum possible requirements in its domain. It is supported by the fact that number of feature requests have also also reduced with time (refer to Table 4.1). Good package design is achieved by perfect balance between abstraction ((A) and instability (I).. Another metric in this metric set known as the Distance from the Main Sequence Sequence, measures this balancing act. 4. Distance ce from the Main Sequence The normalized metric D measures the relation in abstraction (A) and instability (I). The metric takes values nearly zero for a package, if A and I are perfectly balanced balanced. As shown in Figure 4.12,, metric values have improved considerably in successive releases of the software component. Specifically recently after version 1.0.5, it has attained a value near nearly zero. This indicates that on average package design is balanced with respect to abstraction and instability.
Fig.4.12: Distance from the Main Sequence Metric Trend 5. Average -umber of Classes C per Package Number of classes assigned to a package can help us to know the distribution of functionality in different packages. Even distribution of classes indicates a design in which all the packages are assigned equal functionality.. No package is more iintelligent than others in such a system. Figure 4.13 shows the growth of software measured in number of packages in successive releases for JFreeChart software component.. It also shows change in average package size (measured in number of classes). classes). It is observed that average package size is consistently increasing till version JFreeChart 0.9.20 but the increment in size per version is very small. Similarly number of packages in the the software also grows in this time period but this increase is not as sharp as it is after the version JFreeChart 0.9.20. 108
In the succeeding versions a number of packages have been created. created. Average package size has declined for these versions. Overall variation tion in package size is also small, as the plot of standard deviation of the metric on the graph indicates. Shift hift in data values is visible corresponding to the release of 1.0.0 version. Major maintenance activity takes place from version JFreeChart 0.9.20 to JFreeChart 1.0.2. A drop in data values for the these releases indicates that developers have put in significant efforts to reorganize the internal structure of the component, which further continues in later versions as well.
Fig.4.13: Average Number of Classes per Package Metric Trend
4.3.3. Class Level Metrics 4.3.3.1. Selection of Metrics A number of class level metrics are proposed in the research literature. The metric tool used in this research, SDMetrics, collects collect 20 class level metrics to measure size, complexity, coupling, and inheritance related properties of classes in an object oriented design. This research defines some more metrics to to cover different aspects of object oriented paradigm such as information hiding, polymorphism, coupling, and cohesion. cohesion A complete list ist of metrics is given in Table T 4.2. The list mentions 31 class level metrics (which measure different dimensions of the object oriented paradigm) used for the analysis of this software component Then need was felt to exclude the redundant metrics from this large set. Benestad et al. identify various metric selection strategies (Benestad et al., 2006): •
Tool driven selection – select only those metrics which are collected by the tool in hand.
•
Pre-defined defined set of measures - popular sets of measure theoretically as well as empirically validated. 109
•
Evidence based selection – use the metrics which are known to be good predictors of quality in other similar situations.
•
Statistical analysis of structural measures – Statistical analysis is employed to select an independent set of metrics.
This research uses the last strategy, statistical analysis of structural measures, to select an appropriate set of metrics. Principal Component Analysis was used to select an orthogonal set of metrics for further analysis.
4.3.3.2. Principal Component Analysis Different class level metrics have been included in the metric set to measure different properties of the Object oriented program such as size, coupling, cohesion, inheritance, polymorphism, and information hiding. It is important to examine these metrics to determine whether they measure different properties of an object oriented design, or are measuring the same thing. Some metrics in the metric set may be highly correlated with one another i.e. they might not form an independent set. It is not useful to study such metrics separately, which highly correlate with others as they do not measure different dimensions of a design. Principal Component Analysis (PCA) is used as a technique to find a set of orthogonal metrics from the original metric set given in Table 4.2. Principal components (PC) are used to transform the original data set into a smaller set of variables that account for most of the variation. This section focuses on selecting an orthogonal set of metrics. The statistical package SPSS 13.0 is used to analyze 43 versions of the JFreeChart library. Tables A.1-A.43 in Appendix–A, contain the PCA results for each of the versions. Principal components are named PC1, PC2, and so on. For different versions, principal components vary from 6 to 8. An analysis of the Tables A.1-A.43 shows that there is no clear pattern for the metrics falling in different principal components for different versions. A particular PC does not always measure a specific dimension of the software design. No doubt some of the metrics are always together in one PC, but may not be in the same PC for every version. For example metrics EC_Par, CBCM, CBCU, CBCoutM, CBCoutU are always together, but they keep on changing the PC from PC1 (version JFreeChart 0.9.15-JFreeChart 0.9.17) to PC2 (version JFreeChart 0.9.18 - JFreeChart 1.1.10). Table 4.3 gives metrics which always appear together in the same PC in all the versions. 110
Table 4.2: List of Class Level Metrics Collected in This Study. S.-o.
Metric -ame
Description
1.
NumAttr
Number of Attribute
2.
NumOps
Number of Operations
3.
NumPubOps
Number of Public Operations
4.
NOC
Number of Children
5.
NumDesc
Number of Descendents
6.
DIT
Depth of Inheritance Tree
7.
CLD
Class to Leaf Depth
8.
OpsInh
Operations Inherited
9.
AttrInh
Attributes Inherited
10.
NumAssEl_ssc
Number of Associated Elements in the Same Scope as Class
11.
NumAssEl_sb
Number of Associated Elements in the Same Scope Branch as Class
12.
NumAssEl_nsb
Number of Assoc. Elements NOT in the Same Scope Branch as Class
13.
EC_Par
ClClassClass Export Coupling
14.
IC_ParU
Import Coupling with a class counted only once.
15.
IC_ParM
Import Coupling with a class counted multiple times
16.
CBCM
Coupling Between Classes Multiple- counting classes multiple times
17.
CBCU
Coupling Between Classes Unique- counting a class only once
18.
CBCinM
CBC Incoming Multiple – counting a class multiple times
19.
CBCinU
CBC Incoming Unique -counting a class only once
20.
CBCoutM
CBC Outgoing Multiple– counting a class multiple times
21.
CBCoutU
CBC Outgoing Unique – counting a class only once
22.
NumOvrOps
Number of Overridden Operations
23.
NumHidOps
Number of Hidden Operations
24.
CAMC
Cohesion Among Methods of a Class
25.
CAMCs
Cohesion Among Methods of a Class (including Self Parameter)
26.
NHD
Normalized Hamming Distance
27.
NHDs
Normalized Hamming Distance(including Self Parameter)
28.
SNHD
Scaled Normalized Hamming Distance
29.
SNHDs
Scaled Normalized Hamming Distance(including Self Parameter)
30.
NHDM
Normalized Hamming Distance Modified
31.
NHDMs
Normalized Hamming Distance Modified(including Self Parameter)
111
Table 4.3: Metrics that Appear Together in Same PCs in all Versions Group 1
Group 2
Group 3
Group 4
Group 5
EC_Par
IC_ParU
NumAnc
NOC
CAMC
CBCU
IC_ParM
DIT
NumDesc
HDM
CBCM
CBCInU
AttrInh
CLD
CBCOutU
CBCInM
OpsInh
CBCOutM
Coupling metrics are divided into different dimensions. Metrics measuring outgoing dependencies EC_Par, CBCoutU, and CBCoutM, are together in one PC, whereas those measuring incoming dependencies such as IC_ParU, IC_ParM, CBCinU, and CBCInM are together in another PC. CBCM and CBCU measuring both incoming as well as outgoing dependencies, vary consistently along with the former set of metrics with CBCM mostly having the highest loading factor in the group. In group 1, EC_Par explains the greatest amount of variation in the initial versions of JFreeChart (0.9.2-0.9.11) and again surfaces in the later versions as well from JFreeChart 0.9.19 to 1.0.10. IC_ParM varies more in Group 2. In Group 3, DIT varies more frequently in comparison to others in the same group. In the last group, NumDesc varies more. So it was decided to choose EC_Par, IC_ParM, DIT and NumDesc from groups 1, 2, 3, and 4 respectively. All the cohesion metrics vary consistently for some of the versions such as from JFreeChart 0.9.0 to JFreeChart 0.9.1 and then from JFreeChart 0.9.5 to JFreeChart 0.9.8. In other versions, cohesion metrics are divided in different PCs. However cohesion metrics CAMC and HDM always vary together in the same PC throughout the different releases. Other two metrics in this group, HDs and SHDs, also consistently follow each other from JFreeChart 0.6.0 to JFreeChart 1.0.3. However SHDs loads on multiple PCs from JFreeChart 1.0.5 to JFreeChart 1.0.10. CAMC and HDM also appear always together in the same component, except in JFreeChart version 0.9.3 in which HDM loads significantly on two components. HDM loads more significantly than CAMC in most of the versions. So HDM metric is chosen for further analysis. Other three metrics in the coupling category such as umAssEl_ssc, umAssEl_sb, and NumAssEl_nsb rarely appear together in the same component. For initial versions like JFreeChart 0.6.0 to JFreeChart 0.9.2, the metric umAssEl_nsb takes 0 values for all classes. When it takes non-zero values, sometimes it does not have significant loading 112
factor on any of the PCs like in JFreeChart versions 1.0.3-1.0.10 or is loaded on multiple PCs like in JFreeChart versions 0.9.7, 0.9.8. If it has significant loading factor, then it mostly varies with size metrics such as NumAttr, NumOps etc. like in JFreeChart version 0.9.9 to JFreeChart 0.9.16 and then from JFreeChart 0.9.19 to 0.9.21 which means that large sized classes has more associations with classes not in the same hierarchy. In order to see the behaviour of these metrics in all the versions, these three metrics selected for further analysis. Size metrics such as NumAttr, NumOps also appear together with a very few exceptions as in JFreeChart version 0.7.0 to JFreeChart version 0.7.4. NumOps metric is chosen as size metric for further analysis. umHidOps Metric, used to measure information hiding property, appears mostly along with size metrics except in JFreeChart 0.7.3 and JFreeChart 0.9.18. NumOverOps metric, which measures polymorphism property, varies along with NumAnc, DIT, AttrInh, and OpsInh but not very consistently. This metric is picked for analysis further. List of metrics selected for further analysis is given in Table 4.4. Table 4.4: The Selected Set of Metrics. Size/complexity
umOps
Interface Size
umPubOps
Information Hiding
umHidOps EC_Par
Coupling
IC_ParM umAssEl_ssc umAssEl_sb umAssEl_ssc
Polymorphism
umOvrOps
Inheritance
DIT, umDesc
Cohesion
HDM
4.3.3.3. Metrics Analysis 1. Size/Complexity For this study, average class complexity was examined for all releases of the software. Figure 4.14 shows the trend in metric values. It is observed that the average class complexity has increased towards the most recent versions of the software component. 113
Exceptions occur at the transition point from JFreeChart 0.9.20 to JFreeChart 1.0.1. Even though the size of the software released as version JFreeChart 0.9.20 is larger than its subsequent release JFreeChart 0.9.21, its average class complexity is low. Distribution of the responsibilities/functionality in the classes is not even. A plot of standard deviation of the average class complexity on the chart shows that variation in class responsibilities is less in the beginning, it increases after that and reduces only for release JFreeChart 1.0.1 and increases again for the latter versions.
Fig 4.14: Average Class Size Metric Trend
2. Interface Size All the public operations of a class put together form an interface of the class. It characterizes the set of requests that objects of this class can respond to or services they can provide to other objects. The metric trend, as shown in Figure 4.15, indicates that interface size has grown overtime. It was however stable in the initial releases. But after the release of version JFreeChart 0.9.20, average interface size has increased gradually except for two releases JFreeChart 1.0.0 and 1.0.1. In the initial years, a lot of demands were put on the software component (Table 4.1) and this has resulted in increase in functionality in the recent years. Classes have become more responsible (more number of operations) and they have to provide more services to support the overall functionality of the software. As already noted, period from JFreeChart 0.9.20 to JFreeChart 1.0.2 is turbulent growth period. In this time period, effort has been done to restructure the software product. Average Interface Size increases sharply from JFreeChart 0.9.19 to 0.9.20, but it declines in the next release i.e. JFreeChart 1.0.0 and declines further in JFreeChart 1.0.1. However it gradually increases after that. This is not a good trend. For a good design, class interfaces should be small and simple. With large interfaces, there is
114
always a possibility of more interclass interactions and hence difficulty in maintaining the design.
Fig.4.15: Average Number of Public Operations Metric Trend
3. Information Hiding Average number of hidden operations has seen many ups and downs in the trend chart given in Figure 4.16. But now for the recent versions it has almost stabilized. However, average number of public operations per class is much higher than average number of hidden operations. For the latest releases, on average a class has one method as hidden, but has approx 10 methods as public. There is a tradeoff between the number of hidden methods a class has and the amount of functionality it provides. As the functionality of the system (or of individual classes in the system) has increased, number of hidden methods has decreased. This class level metric also supports the information made available by the corresponding system level metric (Figure 4.4).
Fig 4.16: Average Number of Hidden Operations Metric Trend
4. Coupling When two classes depend upon each other, they are said to be coupled. Type of coupling can be categorized on the basis of strength of coupling and direction of coupling. A System with highly (tightly) coupled classes is unstable and difficult to understand and modify. 115
Single change in a class, in such systems, takes a ripple effect and increases the effort required for modification. On the other hand, a system with lowly (loosely) coupled classes is more stable and easier to modify.
Fig.4.17: Import Coupling Metric Trend
Import Coupling is the extent to which a class depends on or has knowledge of external data declarations. More dependent a class is on external declarations, more difficult it becomes to understand the class in isolation. Later on testing and verification of such a class demands more effort and time. Also it is difficult to reuse such a class in a new context, because all the depended upon classes also have to be made available in the new context.
Fig.4.18: Export Coupling Metric Trend
Export Coupling is the extent to which the data declared in a class affects the design and implementation of other classes in the system. Classes with high export coupling may be called library classes. Intuitively in a good design, classes which are importing data should import from a small set of classes and classes which are exporting data should export to a large set of classes. It is important to remember here that a class with many outgoing connections is difficult to change as it has impact on large number of classes in the design. Such classes with high export coupling should preferably be stable and need to be 116
reviewed for potential changes from time to time so that changes can be implemented with minimal impact. Trends in average metric values for import coupling and and export coupling are shown in Figures 4.17 and 4.18 respectively. respectively Both the graphs are roughly presenting the same tren trend except a few cases. It is observed that both the graphs are exactly the same for version JFreeChart 0.9.4 onwards. Before this, average export coupling follows a downward trend after version JFreeChart 0.7.0, but average import coupling follows a downwar downward trend after JFreeChart 0.7.2. Average verage import coupling increases from JFreeChart 0.9.1 to JFreeChart 0.9.4, but average export coupling alternates in ups and downs till version JFreeChart 0.9.4. As per the data plotted, on average a class has more import coupling than export coupling.
Fig.4.19: Import Coupling Metric Trend
Fig 4.20: Export Coupling Metric trend.
In order to study these metrics in detail, standard deviation of these metrics wa was also plotted (Figures 4.19 and 4.20). In case of import coupling, values for individual classes do not deviate much from the average value for the metric, whereas in case of export coupling, deviation from the average values is very large. So it was decided to study frequency distributions of the values of these metrics for different versions (selected 117
randomly). A detailed analysis of the values for these metrics in Table 4.5 shows that export coupling metric EC_Par is zero for majority of the classes, and for some of the other classes it is very high. However, the metric IC_ParU measuring import coupling is non-zero for more number of classes and takes much smaller values in comparison to export coupling metric EC_Par. In almost all the cases discussed in Table 4.5, 70% of the classes do not export any data, and only 10% of the classes export to a large set of classes (from 54-77 for various versions). Table 4.5: Frequency Distribution of Coupling Metrics.
Percentiles 0
JFreeChart 0.7.4
JFreeChart 0.8.0
JFreeChart 0.8.1
JFreeChart 0.9.0
EC_Par
IC_ParU
EC_Par
IC_ParU
EC_Par
IC_ParU
EC_Par
IC_ParU
.
.
.
.
.
.
.
.
10
0
0
0
0
0
0
0
0
20
0
0
0
0
0
0
0
0
30
0
0
0
0
0
0
0
0
40
0
1
0
1
0
0.4
0
0
50
0
1
0
1
0
1
0
1
60
0
1.4
0
1
0
1
0
1
70
1
2
0
2
0
2
0
2
80
2.2
3
2
3
2
3
1
3
90
6
4
6
4
5
4
5.1
4
100
56
9
54
9
56
11
77
11
However, in case of import coupling metric IC_ParU, around 30% of the classes do not import any data, and remaining 70% classes take values ranging from 1-11 for the metric. It shows that a large number of classes are importing data from a small number of classes and a small number of classes are exporting data to a large number of classes. This is a good design strategy as it is possible to manage a small number of classes for changes which may impact many other classes in the software. This small set of classes act as utility or library classes. The coupling metrics discussed in the preceding paragraphs take into account the type (using a class as a data type), and direction (import or export) of connection between a pair of classes. Another aspect of class coupling is to consider location of the class with which a class is coupled. Coupling of a class with other classes in the same scope
118
(namespace/package) is not the same as coupling with classes outside the scope. Coupling of former type is desirable whereas coupling of the latter type is not much desirable. A subsystem represents related functionality. Any changes to classes in the subsystem should be restricted to changes in the classes of that subsystem only. But this may not be the case if classes in a subsystem are connected with classes in other subsystems. In such situations, change impact may take place across the subsystems. This is not desirable. So in a good design, number of connections of a class with other classes in the same subsystem (same scope or same scope branch) should be high, whereas number of connections with classes in other subsystems should be low. The metrics for measuring different types of coupling in this category are: number of associated elements in the same scope as class (umAssEl_ssc), number of associated elements in the same scope branch as class (), and number of associated elements not in the same scope branch as class (umAssEl_nsb). umAssEl_ssc counts only the interactions that a class has within the same package. umAssEl_sb counts the interactions that a class has with classes in other packages, but these packages are nested within one-another. umAssEl_nsb counts coupling between classes which are contained in unrelated packages. As far as average metric values are concerned, as shown in Figures 4.21, 4.22, and 4.23, umAssEl_sb throughout takes values in higher range than the other two metrics. This implies that classes have more connections with other classes in the same branch/hierarchy rather than with classes in a different hierarchy tree. Also umAssEl_nsb is close to zero in the initial versions (except the first one), and ideally it should be so (Figure 4.21). But for the later versions, this metric starts increasing and remains in the vicinity of value 0.20 (except 1.0.1) which is in most cases more than the value that umAssEl_ssc takes for these versions (Figure 4.23). However, graph of the third coupling metric umAssEl_sb in Figure 4.22 shows that in this software component more number of classes are connected with classes in the same branch rather than with classes in the same scope or in the other branch. Both the metrics umAssEl_ssc and umAssEl_sb are following a downward trend, but umAssEl_nsb follows an upward trend. It seems to be a bad practice on the face of it. A deeper analysis of the metric values revealed some more information regarding metrics behaviour. Frequency distributions of these metrics for some of the versions (selected randomly) are given in four Tables from 4.6 to 4.9. The percent of classes that take zero values is maximum (among the three metrics) for umAssEl_nsb metric in all the versions studied in detail here. For metric values other than 0, percentage of classes taking different 119
values is mostly less for the umAssEl_nsb in comparison to other two metrics. umAssEl_sb takes the maximum range of values in the three metrics. This shows that a large number of class interactions are within the same subsystem (may not be within the same scope as class), and class interactions across the subsystems are comparatively less. This is desirable for a good design. So these metrics when studied together indicate a good design as far as coupling within and across the subsystems is concerned.
Fig.4.21: Average Number of Associated Elements in the same scope as class (umAssEl_ssc)
Fig.4.22: Average Number of Associated Elements in the same branch (umAssEl_sb)
Fig 4.23: Average number of Associated Elements not in the same branch as class umAssEl_nsb)
120
Table 4.6: Distribution of Coupling Metrics in JFreeChart 0.9.4 -umAssEl_ssc
-umAssEl_sb
-umAssEl_nsb
value
Classes (%)
value
Classes (%)
value
Classes (%)
0
81.8
0
70.46
0
93.23
1
12.3
1
19.08
1
5.85
2
2.8
2
5.23
2
0.62
3
1.8
3
3.08
3
0.31
4
0.9
4
1.23
5
0.3
5
0.31
7
0.31
21
0.31
Table 4.7: Distribution of Coupling Metrics in JFreeChart 0.9.11 -umAssEl_ssc value
Classes (%)
-umAssEl_sb
-umAssEl_nsb
value
Classes (%)
value
Classes (%)
0
83.83
0
75.94
0
89.85
1
11.47
1
14.47
1
4.51
2
3.20
2
6.77
2
2.63
3
1.13
3
1.88
3
1.88
4
0.38
4
0.56
4
0.38
10
0.19
5
0.19
20
0.19
6
0.19
8
0.38
Table 4.8: Distribution of Coupling Metrics in JFreeChart 1.0.1 -umAssEl_ssc
-umAssEl_sb
-umAssEl_nsb
value
Classes (%)
value
Classes (%)
value
Classes (%)
0
84.66
0
76.14
0
94.70
1
11.17
1
16.48
1
4.73
2
2.46
2
4.92
2
0.38
3
1.33
3
1.52
3
0.19
4
0.38
4
0.76
25
0.19
121
Table 4.9: Distribution of Coupling Metrics in JFreeChart 1.0.2 -umAssEl_ssc value
Classes (%)
-umAssEl_sb
-umAssEl_nsb
value
Classes (%)
value
Classes (%)
0
86.03
0
78.70
0
89.35
1
9.96
1
14.52
1
6.50
2
2.21
2
4.01
2
2.35
3
1.52
3
1.80
3
0.69
4
0.28
4
0.69
4
0.41
5
0.14
5
0.55
28
0.14
6
0.14
5. Polymorphism In a class hierarchy, a subclass inherits operations (public and protected) from its base class. The subclass can use the inherited operations as is or can modify/ extend them. Inherited operations, which are modified, behave differently in the subclass than their counterparts in the base class. Such operations are said to exist in many forms. They are called overridden operations. Overriding is a type of polymorphism, a design property that can help in creating flexible and extendible software designs. Every inherited method is open to polymorphic behaviour in a subclass. A class supports the design property of polymorphism if it redefines the methods inherited from its base classes. But it is not appreciated if a class redefines majority of the inherited methods as it indicates that inheritance hierarchy is created out of convenience rather than modeling the real world in a natural way. This research uses number of overridden operations (umOvrOps) metric to measure the extent to which a class supports polymorphism. In Figure 4.24, average number of overridden operations is high for the early versions, but decreases after that and follows an upward trend for the recent releases. It is important to study this metric in the light of another related metric and that is average number of inherited operations (OpsInh). It is observed that average OpsInh, as shown in Figure 4.25, also follows the same trend in the versions starting from JFreeChart 0.9.13. Before this release, it is not following any consistent trend but it takes values in a low range in comparison to the values it takes in the latest releases. In the initial versions operation overriding is more. It is controlled for the middle versions and follows an upward trend for the latest versions. Nonetheless OpsInh metric also rises for the versions 122
towards the end. But the number of operations on average a class overrides is proportionally very less in comparison to the number of operations it inherits. This is a good design practice as a large number of overridden operations are not desirable for a good design. If a class overrides a large number of inherited operations it indicates that it is modifying or cancelling the behaviour of its base class, which it should otherwise only extend to support the generalization/specialization generalization/specializatio relationship. It is suggested that nnumber of operations that a subclass overrides should be less than 4 (Breesam,, 2007) 2007). On the other hand the number of operations inherited from the base class indicates the strength of sub classing by specialization (Lorenz & Kidd, 1994). The number of inherited methods should be high, smaller number indicates poor sub classing. Metric trends show that average number of overridden operations opera for a class varies from 0.59 to 1.35 operations, whereas average number of inherited inherited operations for a class varies from 8 to 25 operations in different versions of the software component. Number of overridden operations is comparatively very less than number of inherited operations. So classes are using the concept of polymorphism but are not overusing it. System level Polymorphism Metric (PF) in Figure 4.7 also indicates the same.
Fig.4.24 4.24: Average Number of Overridden Operations
Figure 4.25: Average Number of Inherited Operations
123
6. Inheritance The inheritance mechanism makes the software design more organized. Inheritance means that a class can inherit attributes/operations as defined in its parent class, and can also extend/restrict the behaviour by adding new operations or by modifying the inherited operations. The shape pe and size of the inheritance tree structure can be known with the help of Inheritance metrics. These metrics are number of descendents (umDesc) (umDesc), Depth of Inheritance Tree (DIT), and Number of children (OC). umDesc metric for a class counts the number of its subclasses, subclasses of its subclasses and so on. DIT metric measures the depth of a class from the root ro of the hierarchy, and OC measures the number of immediate children of a class class. In a good inheritance tree ee structure, cclasses near the top are expected to have large number of children in comparison to classes deep in the hierarchy. Classes in the deep hierarchy are more specialized and cannot provide abstraction to support a large number of classes. In Figures 4.26 and 4.27,, trends for the metrics OC and umDesc are exactly the same. Both the metrics are following a downward trend with the evolution of the software component. As per the metric definitions, umDesc always takes values larger than OC as it is an aggregate of values of OC metric for different classes in the hierarchy. It is more appropriate to study the OC metric further to know more about the behaviour of these metrics at different levels of the inheritance hierarchy. Figures 4.28 tto 4.31 show the values of OC metric at different level of hierarchy (DIT metric values on xx-axis) for various versions (selected randomly). It can be observed that OC takes larger values at deeper level of hierarchy. This is not a good design strategy as abstraction in the design should be at higher levels of hierarchy. This anomaly is present in all the versions examined here.
Figure 4.26: Average Number of Children
124
Fig 4.27: Average Number of Descendents
Fig.4.28: Scatter Diagram of NOC and DIT for JFreeChart 0.5.6.
Fig 4.30: Scatter Diagram of NumDesc and DIT for JFreeChart 1.0.1
Fig.4.29: Scatter Diagram of NOC and DIT for JFreeChart 0.9.20.
Fig 4.31: Scatter Diagram of NumDesc and DIT for JFreeChart 1.0.10
DIT metric can help us to know whether the inheritance tree is broad and shallow or is narrow and deep. It is observed that software designs with broad and shallow inheritance
125
structures tructures are more suitable for reuse, as they represent more general concepts and are also easier to modify and extend.
Fig Fig.4.32: Average Depth of Inheritance Tree
In this software component, component average class DIT has remained ined around level 1 as seen in Figure 4.32. Maximum value of DIT sees some ups and downs and gets settled down at level five (starting from zero) in the latest versions. According to Lorenz and Kidd (1994), six levels of hierarchy are enough to describe any real world phenomenon in the form of a hierarchy. Figures 4.33, 4.34, and 4.35 provide information about number of classes (in percent) at a particular level and number of levels in the inheritance tree structure for different versions. Blue part of the stacked bar represents classes with DIT=0, red part shows classes with DIT=1 =1 and so on. In the initial releases, inheritance tree was deep with six levels. For one version JFreeChart 0.8.1, the tree had even seven levels of hierarchy, but in the very next release JFreeChart 0.9.0, structure was improved and had only five levels. So inheritance tree structure evolved from a deep structure to a shallow one. In the latest releases, tree structure has six levels of hierarchy, but number of classes at the deepest level is very less in comparison to the initial releases.
Fig.4.33: Evolution of Inheritance Structure for Initial Versions of the Software Component
126
A look at the percent of classes at each level shows that in the initial versions (JFreeChart 0.7.1 to JFreeChart 0.8.1), ), tree structure is narrow and deep as well (see Fig. 4.33) 4.33). But it starts broadening after JFreeChart 0.8.1 onwards. The inheritance tree for succes successive versions remains wide at level one (DIT=1) as shown in Fig. 4.34, and it remains shallow and goes on getting broader for the latest releases as well (see Fig. 4.35).
Fig. 4.34: Evolution of Inheritance nheritance Structure for Middle Releases of the Software oftware Component.
Fig.4.35: Evolution of Inheritance nheritance Structure for Latest Releases of the Software oftware Component.
7. Cohesion Cohesion is the degree of interrelatedness of members of a class. Cohesion ohesion of a class at design level is earlier discussed in Chapter 3 of this thesis. thesis. In the design specification of a class, its members (data and operations) are defined. Operations are no not implemented at this level, only their signatures are available. A few cohesion metrics have been defined at design level, whereas a large number of cohesion metrics exist at source code level. This research discusses cohesion ohesion metrics proposed by Bansiya et al. (2002) and Counsell et al. (2006) and proposes a modification of the th existing metrics to remove the anomalies present in their definitions.. The modified metric is named HDM, where M stands for ‘Modified’.
127
HDM is selected for further analysis, because beca it has more variation in its values in comparison to other cohesion metrics. metrics As shown in Figure 4.36, HDM is following a downward trend across various releases of the software component. On average cohesion of a class has decreased, and this is not a good trend. A large sized class is expected to have less cohesion. This is confirmed from the data given in Figure ure 4.14 and F Figure 4.36 except a few exceptions. As the average class size increases, average cohesion drops. Visible differences can be observ observed from JFreeChart 0.5.6 to JFreeChart 0.6.0 and from JFreeChart 0.9.20 to JFreeChart 1.0.2. Exceptions in trend correspond to versions from JFreeChart 0.9.4 to JFreeChart 0.9.7. This research studies design level cohesion in detail so it is interesting tto study the behaviour of different cohesion metrics as the component evolves. CAMC shows the same trend in average metric values as HDM (Figuress 4.36 and 4.37) 4.37). CAMC has comparatively larger values than HDM. As discussed in chapter 3, there are some anomalies in the definition of the CAMC metric. It just counts the number of 1s in the parameter occurrence matrix without considering the agreements in method pairs on different parameters. CAMC also gives false positives ositives as pointed out in the earlier discussion in chapter 3.
Fig.4.36: HDM Metric Trend
Both the metrics CAMC and HDM are showing negative trend. However, as shown in Fig. 4.38 the HD metric is almost co constant nstant for successive versions, but it takes very large values in comparison to CAMC and HDM. It has been observed that HD takes large values for large sized classes (Counsell et al., 2006) but in this analysis HD does not grow with the same intensity as the class size grows (see Figure 4.14). The he claim regarding CAMC, that it takes high value for small classes and a low value for large classes classes, is however confirmed in this study as well. So CAMC metric measures the intent of cohesion more correctly than HD. HD No doubt, there are some loopholes in its definition, but HD 128
also suffers from same kind of problems. Authors in (Counsell et al., 2006) suggest that HD metric values should be interpreted in the light of values of another metric - the Scaled HD (SHD) metric. SHD metric helps to know the closeness of HD metric to its maximum value or its minimum value. Negative values of SHD indicate that HD is more close to its minimum value and vice versa. In Figure 4.39, all the releases have negative values for the SHD metric. Variants of the cohesion metrics for a class are defined by considering the self parameter as one of the parameters of all the methods of a class. An object uses this type of parameter to pass its own state to its member methods (for ex. the ‘this’ ppointer in C++ and JAVA). These variants are denoted by CAMCs, HDs, SHDs, and HD HDMs corresponding to CAMC, HD, SHD,, and HDM respectively. Values for these variant metrics are more than their respective counterparts. This means that cohesion of a class is more if ‘self’ parameters of its methods are considered, and it is intuitively true as well because all methods of the class agree at least on one parameter. For two sets of metrics CAMC, CAMCs, and HDM, HDM HD s variants take larger values but trends for the metrics remain the same. The larger values may be due to the addition of more cohesive interactions in class definitions. On the other hand hand, HDs has a lot of variation in comparison to HD (refer to Figures 4.38 and 4.42). 4.42) HDs is comparitively more consistent with the increasing size of classes than HD. HD. As the average class size increases in successive versions (Fig.4.14), HDs also increases. As shown in Figures 4.39 and 4.43, SHD is throughout negative whereas SHDs is throughout through positive. It shows that HD is close to its minimum whereas HDs is close to its maximum. maximum Intuitively classes (considering self parameter for methods) are comparatively cohesive than their counterparts. Metric variants (with self parameters) also indicate the same when this small cohesive interaction is added to a class. It can be concluded that for a class with low level of cohesion, NHD metric is close to its maximum.
Fig.4.37: CAMC Metric Trend.
129
Fig.4.38: HD Metric Trend.
Fig.4.39: SHD Metric Trend.
Fig.4.40: CAMCs Metric Trend
Fig.4.41: HDMs Metric Trend
130
Fig.4.42: HDs Metric Trend
Fig.4.43: SHDs Metric Trend.
4.3.4. An Investigation ion of the JFreeChart Class A detailed evaluation of one of the core classes of the software component is undertaken to see as to how it has evolved over the years. This class is known as the JFreeChart class. It is a part of the software component since its inception. Metric trends rends have been studied for size, information hiding, inheritance, coupling and cohesion properties. 1. Size metrics
Fig.4.44: Size Metrics for the JFreeChart Class
131
As presented in Figure ure 4.44 4.44,, class has grown considerably in the successive versions. New methods have been added gradually. But most of the newly added methods are public to other classes. However in the later versions, versions number of hidden methods ethods is proportionately more in comparison to earlier versions. 2. Inheritance metrics JFreeChart is a standalone class. It is placed at DIT level 0. It had only one child initially, that too was removed in version JFreeChart 0.8.1 (Figure 4.45).
Fig.4 .4.45: Change in NOC Metric for JFreeChart class
3. Coupling Metrics It may be noticed that when the child class is removed, coupling which was under control till then, starts increasing considerably. Coupling value drops for 0.9.21, it may be because a large number of classes are removed from the version JFreeChart 0.9.20. Different types of coupling metrics shown in Figure Fig 4.46 indicate that coupling of this class with other classes in the same scope branch (package) increases (the umAssEl_sb metric), but coupling upling is negligible with classes outside the (package) scope (the umAssEl_nsb metric).
Fig.4.46: Fig.4.46 Coupling Metrics for the JFreeChart Class
Another kind of coupling information is revealed in Fig. 4.47 4. by trends for the metrics CBCinU and CBCoutU metrics, which measure import and export coupling respectively. 132
Metric trends indicate that throughout the various releases, export coupling has remained high in comparison to import coupling. The class exports on average to a larger number of classes but ut imports information from a smaller small set of classes so it acts as a library class. class A lot of classes are removed in the evolution from version JFreeChart 0.9.20 to JFreeChart 0.9.21, value for export coupling metric CBCoutU also reduces drastically in this change. Import coupling metric CBCinU shows no variation (except slight change from version JFreeChart 1.0.0 to JFreeChart 1.0.1). This again is a good sign as the classes on which this class depends upon do not change (or are not removed). However, expor export coupling metric starts growing again.. From the trends for coupling metrics, it can be concluded that the class has desirable kind of interactions with other classes in the system.
Fig 4.47: 4. Coupling Metrics for the JFreeChart Class
4.
Cohesion Metrics
In the beginning cohesion was high at some points, but as size of the class starts growing value of the cohesion metrics metric drops (Fig. 4.48). Except two metrics (HD HD and HDs), all other metrics depict this trend. HD and HDs are almost at the same level throughout.
Fig.4.48 48: Cohesion metrics for the JFreeChart Class 133
4.4. Comparison with the Thresholds Metrics thresholds are the benchmarks that help to answer questions related to the quality levels achieved in the design of a software program and act as a guide to developers to concentrate on problematic parts of the program in order to improve it further. Different techniques are available to identify the metrics thresholds: •
Researchers and practitioners, using their own experience, recommend values for metrics thresholds. For example, it is recommended that depth of a class in the inheritance tree should not be more than six as any real world phenomenon can be classified using this many levels of hierarchy (Lorenz and Kidd, 1994).
•
Thresholds may also be identified using statistical techniques such as by using mean and standard deviation information for a metric (Erni and Lewerentz, 1996) or by following the 80/20 rule (Chidamber and Kemerer, 1998). Classes whose metric values are beyond the threshold values are assumed to be risk prone. This kind of analysis compares classes in a design with other classes in the same design.
This section analyzes the metrics values collected from the reusable component for their threshold ranges. Last version (studied in this research) of the software component i.e. JFreeChart 1.0.11 is taken into consideration here. Tables 4.10 to 4.12 show different metrics (for which thresholds are available in the literature) used in this research and the values that they take for the JFreeChart 1.0.11 software component. These values are compared with values suggested by researchers and practitioners. Last column of the table gives the sources for the recommended thresholds. It can be observed that for most of the metrics (Table 4.10) for an average class, values do not cross the thresholds suggested by researchers and practitioners. A look at the number of classes tells that in this component majority of the classes fall below the threshold values. In package level metrics (Table 4.11) relation cohesion (H) and distance from the main sequence (D) are the two metrics for which thresholds are recommended in the literature. Both the metrics are above the thresholds, but their averages are very close to the suggested values especially of the D metric. However, only 12% of the packages take values within the suggested range for the relation cohesion metric. There is not much experimentation at the level of system metrics to make suggestions for thresholds for these metrics. Some general guidelines exist to suggest the range in which the metric values should lie. Almost all the system level metrics for the JFreeChart 1.0.11 software component (Table 4.12) are within their threshold ranges. 134
Table 4.10: Class Level Metrics Values against the Thresholds Suggested by Researchers and Practitioners Metric -ame
Observed Value Suggested Value Outliers
Source
NumOps
12.11
12
27.2%
Lorenz and Kidd, 1994
NumPubOps
11.04
