Introduction to Object-oriented metrics

http://blog.csdn.net/horkychen/article/details/7640335

Original address: http://agile.csc.ncsu.edu/SEMaterials/OOMetrics.htm < omit the first part of the description >2 Measurement Analysis

The CK (chidamber kemerer) measure set [8] and mood [measure set] are often used when parsing code in object-oriented metrics. In this section, we will enumerate and explain the specific use of metrics.

2.1 Coupling

1974, Steven et. In the context of structured programming, the coupling is first defined as the "inter-module correlation strength indicator [21]". For object-oriented development, coupling is the index of interdependence among two objects. For example, if object A and a method of calling object B or accessing one of its properties, then the two objects are coupled.

The coupling exponent (CF) is a fractional type. The numerator represents the number of coupling between non-inheriting objects. The denominator is the total number of coupled objects in the system. The total number of coupled objects includes both the coupling between the inherited objects and the non-inheriting objects. Inheritance-based coupling appears in derived classes (subclasses) to access the methods and properties of the base class (the parent Class). CF metrics are included in the mood metric suite.

The experimental data supports the benefits of low coupling between objects [6,7,20]. The main argument is that the stronger the coupling between software components, (i) the more difficult it is to understand the individual components (artifacts, artifact) to properly maintain or improve, (ii) the increasing sensitivity of the components to unexpected changes and defects; and (iii) Therefore, more testing is required to achieve satisfactory reliability. In addition, the over-coupling between objects is inconsistent with the modular design and is not conducive to reuse. In short, low coupling is desirable.

2.2 Cohesion

Cohesion refers to how the various operations of a class are closely interrelated. The cohesion of a class that can represent the degree to which an internal operation of a class is associated with its instance variable. CK Metric Rally locom (the method lacks a cohesive exponent), which refers to the number of methods that access one or more of the same properties [12]. If no method accesses the same property, its value is 0.

There are at least two different methods for measuring cohesion:

1. One is to calculate the proportion of the total number of methods used by this data field for each data field. Then take the average and subtract it by 100%. A lower percentage represents better cohesion.
2. If methods access the same properties, they must be similar. The number of disjoint collections produced by the intersection of attributes used by the calculation method. What is a disjoint set? point here. The expression here is too complex. Reference << Software Engineering >> description, such as a class with 6 methods, where 4 methods have one or more properties that are the same (they use a common attribute), then locom=4, the internal poly metric is 2 (6-4). }

High cohesion shows the refinement of a good class function: Comparison with a single responsibility principle}. Lack of cohesion or low cohesion increases the complexity of the class, thereby increasing the risk of errors during development. A class with low cohesion may be subdivided into two or more sub-classes to increase cohesion. This metric can be used to evaluate design implementations and reusability.

2.3 Package

Information hiding is a design rule, for example, a user with only one module can only understand the public interface of the module. Information hiding is embodied in object-oriented language as "encapsulation".  "Encapsulation means that all objects can be seen as an interface, which is what an object can be executed [17]". Information hiding is a kind of technical theory, and it proves its value without dispute in practice. The study found that large programs that use information hiding are 4 times times more likely to be modified than those that do not use this technology [4,18].

The following two are package metrics that are included in mood. A property can be understood as a member variable. }

2.3.1 attribute hiding factor (AHF)

The attribute hides a factor in the test class for properties that are not visible (invisibility). An invisible (invisibility) property is the percentage of a class that cannot access the property. Note that this property is also considered visible if the property can be accessed through another class or object. The property should be "hidden" within a class. They can be declared private to remain hidden.

The attribute-hiding factor is a fractional. A molecule is the sum of the number of properties that are not visible in all classes. The denominator is the sum of the number of properties defined in each class in the project [10]. The larger the factor, the better.

2.3.2 method hiding factor (MHF)

The attribute hides the factor in the test class for non-visible (invisibility) methods. Invisible methods refer to the percentage of classes that cannot access some methods.

Similarly, the method hiding factor is also a fractional formula, which is the sum of the number of methods that are not visible in all classes. The denominator is the total number of methods defined in the project's various categories.

Methods should be encapsulated (hidden) inside the class and cannot be used for other objects. Method hiding can improve reusability in other programs and reduce complexity. If you want to change the functionality of a method, all objects accessing the method will be affected without hiding this method. Therefore, method shadowing can also reduce code modification [10]. This value should also be as large as possible.

2.4 Inheritance

Inheritance reduces complexity by reducing the number of methods, but this abstraction of objects brings difficulties in maintenance and design. There are two indicators to measure the depth and breadth of the inheritance hierarchy.

2.4.1 Inheritance Depth (DIT)

The inheritance depth is defined as the maximum length from the root node to the sub-class node in the class hierarchy. In cases where multiple inheritance is involved, the DIT refers to the maximum length from the root node to the leaf node [8].

A well-structured object-oriented system has a forest structure of a class, not a large inheritance structure. The deeper the hierarchy of a class, the many methods it inherits to make it more complex to predict its behavior, and therefore more prone to error [15]. The deep-seated follow-up brings greater design complexity to the tree, as it involves numerous methods and classes [8]. In fact, deep-seated is also a puzzle of conceptual integrity, because it is difficult to determine which class is a particular form [3]. In addition, the interface changes in the inheritance tree are necessarily reflected in the entire inheritance tree and related object instances. However, the deep inheritance tree is more reusable than the inherited method [8].

If there are too many classes near the root node, the application can be considered "top-heavy" and also means that it is not possible to obtain the benefit of method multiplexing due to inherited methods. In addition, the application can become a "pyramid" structure by adding classes at the bottom of the class hierarchy, resulting in confusion over design complexity and conceptual integrity.

2.4.2 Number of sub-categories (NOC)

This indicator is the number of direct subclasses of each class. Classes with a large number of subclasses are difficult to modify and often require more testing because one modification affects all subclasses. They are also considered to be highly complex and highly flawed, and must be more flexible to serve a large number of scenarios [3].

2.5 The weighted method of the 2.5.1 class of complexity (WMC)

WCM measures the complexity of a single class. Classes that hold more member functions are often considered more complex and therefore more prone to error [3]. The more methods in a class, the greater the potential impact on the subclass. A large number of methods of the class may be specific to the application and limit the level of code reuse. Therefore, fewer methods are good for usability and reusability of the design.

However, the recent trend in software development is to support more, smaller methods that replace fewer, larger methods to reduce complexity and increase readability [13]. This contradicts the previous conclusion. Suggestions for recommending more and smaller methods are now becoming more prudent. However, in a large inheritance structure there are numerous methods that are absolutely undesirable.

In general, it is considered that the calculation of WMC takes into account the complexity of the various methods (the complexity of the cyclomatic, the number of other posts} and the method, and may have different weights [12].

The simple point is the sum of the cyclomatic complexity of each method. }

2.6 Other metrics 2.6.1 number of classes

For projects with the same functionality, the more classes represent better abstractions. There is no real meaning in the following:

2.6.2 Line of code: most traditional metric}

Projects with the same functionality, the less code {comment: No comments and Blank lines. , which means better design and less maintenance costs.

In addition, an oversized approach always faces high-risk attributes such as accessibility, reusability, and maintainability.

2.7 Measurement Overview

The following table summarizes the indicators discussed above, which indicates whether, in general, a high or low indicator value corresponding to the good quality of the code {The lower representation, the better}. However, it is still necessary to find out in practice which items are the most appropriate assessment indicators for the work in hand.

Table 1: Metrics Summary Table

/tr> tr>

metrics	value
Coupling factor	Lower {Note: The lower the better, the same as the same.}
Method missing cohesion index	Lower
Cyclomatic complexity	Lower
Property Hide factor	More High
Method Hide factor	High
Depth of inheritance tree	Low (tradeoff)
Number of subclasses	Low (tradeoff)
Class Weighted method	Low (tradeoff)
Number of classes	High
code line	Lower

Reference documents

[1] Abreu, F. B. E., "The MOOD Metrics Set," presented at Ecoop ' Workshop on Metrics, 1995.

[2] Abreu, F. B. E. and Melo, W., "Evaluating the Impact of OO Design on software Quality," presented at third Internation Al Software Metrics Symposium, Berlin, 1996.

[3] Basili, V. R., Briand, L. C., and Melo, W. L., "A Validation of Object Orient Design Metrics as quality indicators," C1>IEEE transactions on Software Engineering, vol. 751-761, pp. 1996.

[4] Boehm, B. W., "Improving software Productivity," IEEE computer, pp. 43-57, September 1987.

[5] Briand, L., Emam, K. E., and Morasca, S., "Theoretical and empirical Validation of software Metrics," 1995.

[6] Briand, L., Ikonomovski, S., Lounis, H., and Wust, J., "Measuring the quality of structured Designs," Journal of S Ystems and Software, vol. 2, pp. 113-120, 1981.

[7] Briand, L.. C., Daly, J. W., and Wust, J. K., "A Unified Framework for coupling measurement in object-oriented Systems, " IEEE transactions on software Engineering, vol, pp. 91-121, january/february 1999.

[8] Chidamber, S. R. and Kemerer, C. F, "A Metrics Suite for Object oriented Design," IEEE transactions on software E Ngineering, vol. 20, 1994.

[9] Churcher, N. I. and Shepperd, M. J, "Comments on ' A Metrics Suite for object-oriented Design '," IEEE transactions On software Engineering, vol, pp. 263-5, 1995.

[Ten] Coad, P., "TogetherSoft Control Center," pp. http://togethersoft.com.

El Emam, K., "A Methodology for Validating software Product Metrics," National the Council of Canada, Ottawa, on Tario, Canada ncr/erc-1076, June June 2000.

[Fenton], N. E. and Pfleeger, S. L., software metrics:a rigorous and practical approach: Brooks/cole Pub Co., 1998.

Fowler, M., Beck, K., Brant, J., Opdyke, W., and Roberts, D., refactoring:improving the Design of Existing code< /c1>. Reading, Massachusetts:addison Wesley, 1999.

[Glasberg], D., Emam, K. E., Melo, W., and Madhavji, N., "Validating object-oriented Design Metrics on a commercial Jav A application, "National Council 44146, September 2000.

[Gustafson], D. A. and Prasad, B., "Properties of software Measures," in formal aspects of measurement, T. Den Vir, Ed. New York:springer-verlag, 1991.

[+] Harrison, R., Counsell, S. J., and Nithi, R. v., "An Evaluation of the MOOD Set of object-oriented software Metrics," IEEE transactions on software Engineering, vol, pp. 491-496, June 1998.

[Jacobson], I., Christerson, M., Jonsson, P., and Overgaard, G., object-oriented software engineering:a use case D Riven approach. Wokingham, England:addison-wesley, 1992.

[+] Korson, T. D. and Vaishnavi, V. K., "An empirical Study of modularity in program modifiability," empirical Studie S of Programmers, pp. 168-86, 1986.

[Schneidewind], N. F., "Methodology for Validating software Metrics," IEEE transactions on software engineering vol, pp. 410-422, 1992.

[Selby], R. W. and Vasili, V. R., "Analyzing Error-prone Systems Structure," IEEE transactions on software Engineer ING, vol, pp. 141-152, 1991.

[Stevens], W., Myers, G., and Constantine, L., "structured Design," IBM Systems Journal, vol. 60-73, pp. 1 974.

(image from: http://blog.optimyth.com/wp-content/uploads/2011/12/software-metrics.jpg)

Introduction to Object-oriented metrics