Article Analysis Essay on A Metrics Suite for Object Oriented Design

Introduction

The article A Metrics Suite for Object Oriented Design was authored by Shyam R. Chidamber and Chris F. Kemerer. The study on this subject was intrigued by the increasing significance of software development in the delivery as well as the application of information technology. With the increasing technological advancements, managers are increasingly placing precedence on process enhancement particularly in the software development area. Increased demand for better technologies has fostered the provision or enhanced approaches to software development. Object orientation according to the researchers is the most prominent. Moreover, the study was also intrigued by the fact that process improvement has increased the need for software metrics is essential especially when the organization is implementing a new technology. The researchers sought to address these rising needs by developing a new suite of metrics for object-oriented design. The authors used an automated data collection tool that they developed and implemented to collect a sample of the metrics at two field sites so that they could demonstrate their viability and recommend ways through which managers can use these metrics for the improvement of their processes. Their research was based on past literary studies on software development processes. The Chidamber and Kemerer metrics suite comprised of six metrics that were calculated for every class. The six classes consisted of DIT, WMC, NOC, LCOM1, RFC, and CBO. This paper seeks to provide a report of Shyam R. Chidamber and Chris F. Kemerers article A Metrics Suite for Object-Oriented Design.

If this sample essay on"Article Analysis Essay on A Metrics Suite for Object Oriented Design" doesn’t help,
our writers will!

Trust an expert

Weighted Methods per Class (WMC)

This was the first metric that the researchers looked into. They simply defined it as a method count for a class. It refers to the number of methods that are defined in class. They stated that it is always prudent to keep weighted method per class as low as possible. They stated that a higher WMC in most cases results in more faults or errors. Furthermore, classes that have numerous methods have a higher likelihood of being more application specific, thus reducing the possibilities of reuse. The researchers also found out that WMC can be used as a predictor of how much effort as well as the time needed to develop and sustain a class. Moreover, a big number of methods also depict a greater potential effect on derived classes. This is because the derived classes inherit a portion of the techniques of the base class. Looking for WMC that have high values to identify classes which could be restructured into many classes that are much smaller. According to the researchers, there are various ways of enhancing WMC. One of the ways that they found out is to limit the number of methods in a class to around 20 or 50. Specifying that a maximum of 10% of classes to contain more than twenty-four methods is another better way of improving a WMC . This is because this will allow large classes, however; the majority of the classes should be small. According to the study of 30C++, the findings suggested that an increase in WMC leads to an increase of the density of bugs and reduces the quality.

Shyam R. Chidamber and Chris F. Kemerer found an interesting data in their in-depth evaluation of WMC. The most interesting aspect of the data was the similarity like the distribution of the values at both site A and B regardless of the differences in people involved in their design, the nature of the application as well as the languages used (Smalltalk and C++). They interpreted this finding that most classes tend to have a small number of methods of between 0 and 10. For instance, in their case scenario, the outlier classes at site A showed some unique observations. The class that had the highest number of methods (106) had no children whereas the class that had 87 methods had about 14 subclasses as well as a total of 43 descendants.

Depth of Inheritance Tree (DIT)

This was the second metric that was looked into by the authors. According to them, a depth inheritance tree refers to the maximum inheritance path from the class to the root class. They drew their theoretical basis on Bunges notion of the scope of properties. According to Bunges notion DIT measures how many ancestor classes can affect this class. According to the researchers the deeper a class is found in a hierarchy, the larger the number of methods it is most likely to inherit. This makes it harder and complex to make a prediction of its behavior. Another finding by the researchers was that deeper trees were made up of greater design complexity because more classes and methods are involved. Furthermore, the deeper a specific class is in the hierarchy, the higher the possibility for reuse of methods that are inherited. Inheritance, in this case, infers to a tool that is used to manage complexity, particularly, not to increase it. Deep roots as a positive factor foster reuse because of the inheritance method. A higher depth of inheritance tree according to the researchers has been found to accrue more errors and faults. But it is not necessarily the groups deepest in the class hierarchy that have the highest faults. Another study by Grasberg et al. indicates that majority of the error-prone classes are mostly the ones that are in the middle of the hierarchy tree. Further, according to these researchers the root, as well as the deepest classes, are often consulted and as a result of their familiarity error-proneness as compared to middle classes. The most appropriate DIT should be 5 or even less. This is because an excessively deep class hierarchy is much complex and hard to construct.

Based on Shyam R. Chidamber and Chris F. Kemerers evaluation, both sides A and B libraries had low median figures for the DIT measure or metric. This was interpreted that it depicts that majority of the classes in an application are often much closer to the root of the hierarchy of inheritance. By simply observing a DIT metric for classes in an application, a manager, a leader or a senior designer can easily determine whether the design has too many classes near the root top heavy or bottom heavy that is the majority of the classes are near the bottom of the hierarchy. In their case, they found that the library was top heavy indicating that designers were most likely not taking advantage of reuse of methods by inheritance. The researchers fathomed that some designers might be neglecting reusability by inheritance thus intriguing the need of obtaining metrics of design complexity since a clearer picture of the conceptualization of software systems incepts with special attention on design tradeoffs. It was also determined that there are special classes. This occurs when a class inherits directly from the system.

Number of Children (NOC)

The third metric that was discussed by the researchers was about the number of children. Shyam R. Chidamber and Chris F. Kemerer defined NOC as the number of the intermediate subclasses subordinated to a class in the hierarchy of the class. The number of children equals to the number of immediate child classes that are obtained from a base class. The researchers based their theory on the scope of properties that measures how many subclasses are going to inherit the techniques of the parent class. The main viewpoints drawn from the evaluation is that the higher the number of children, the higher the reuse because inheritance is also a form of reuse. Also, the number of children provides an idea of the possible influence a class can have a particular design. For instance, if a class has a huge number of children it is more likely to need thorough testing of the methods in that class. Furthermore, the study indicated that the higher the number of children the higher the possibility of improper abstraction of the main class. For instance, if a class has a huge number of students, there is a higher likelihood that it may cause misuse, especially in subclassing.

Furthermore, a number of children determines the breadth of a class hierarchy, where the depth is measured by the maximum DIT. Breadth is less great than depth. This is because it fosters reuse of methods through inheritance. Also notably DIT and NOC are closely related. The depth can be increased as well as the breadth reduced in inheritance levels. A high number of children, a huge number of classes, were determined to indicate some things including the base class that might require more testing, high reuse of base class, misuse of subclassing and improper abstraction of the parent class. Overall, it was determined that a high number of children indicate fewer faults. This is mainly pegged on the high reuse which is desirable. Another observation made is that a class that has a high NOC, as well as a high WMC, shows complexity mostly at the top of the class hierarchy. Such a class is influencing a big number of descendants.

Coupling Between Object Classes (CBO)

The fourth metric discussed was the CBO which they defined as the number of other classes to which is coupled. The researchers based their argument on the notion of an object being coupled to another object. Two classes are said to be coupled when methods stated in one class use methods defined by another class. Many accesses to one class are termed as a single class. Only variable references and method calls are counted. Types of references such as calls to API, object instantiations and handling of events are ignored. For polymorphic calls, all other classes to which a call can be connected to is encompassed in the coupled count. Based on the article the researchers found out that a high CBO is much desirable than a low CBO. Too much coupling among object classes is harmful to modular design and limits reuse. Furthermore, the more an independent class is, it is said the easier it becomes to be reused in another application. Inter-object class couples need to be maintained as minimum as possible to enhance modularity as well as foster encapsulation.

Response to Class RFC and RFC

These are a set of methods that can be executed in response to a message obtained by an object of that particular class. According to the researchers, RFC simply denotes the number of methods in a particular set. The difference between RFC and RFC is that the first is a first step measure while the latter is a full measure. A given method is counted as R and or R only after it is executed by different methods. Based on the findings a higher RFC is considered as undesirable and produces more faults. Classes that have higher RFC are considered as more harder and complex to understand. In particular debugging and testing is much complicated. The use of RFC is much more preferred than RFC.

Lack of Cohesion of Methods (LCOM)

The last metric discussed by the Chidamber & Kemerer metrics suite is the lack of cohesion of methods. This metric has accrued great critiques, as well as many other alternatives, have also been created. These researchers found out that there has to be a good cohesion between the methods. In their findings, they found out that the higher the CBO as well as the WMC, the lower the quality of the system. This is also true as in the case of LCOM1.