32 Object Oriented Metrics

“Metrics” is used to mean a set of specific measurements taken on a particular item or process. Software engineering metrics are units of measurement that are used to characterize:

  • Software Engineering Products
  • Software Engineering Processes
  • Software Engineering People

Software engineering metrics is used to quantitatively define success and failure for a product, a process, or a person. It is used to Identify and quantify improvement, make meaningful and useful managerial and technical decisions. It is also used to identify trends and make quantified and meaningful estimates. The various Characteristics of Object Oriented Software Engineering Metrics include

  • Localization.
  • Encapsulation.
  • Information Hiding.
  • Inheritance.
  • Object Abstraction Techniques.

Localization is the process of placing items in close physical proximity to each other. Functional decomposition processes localize information around functions. Data-driven approaches localize information around data. Object-oriented approaches localize information around objects. There are some aspects with respect to conventional software and object oriented software:

Conventional software localization is based on functionality. A great deal of metrics gathering has traditionally focused largely on functions and functionality. Units of software were functional in nature, thus metrics focusing on component interrelationships emphasized functional interrelationships. In object-oriented software localization is based on objects. Instead of functionality provided by an object, at least some of our metrics identification must recognize the “object” as the basic unit of software. Within systems of objects, the localization between functionality and objects is not a one-to-one relationship. Encapsulation is the packaging (or binding together) of a collection of items. Low-level examples of encapsulation include records and arrays and subprograms. Objects encapsulate in which knowledge of state, whether statically maintained, calculated upon demand, or otherwise. The advertised capabilities and the corresponding algorithms used to accomplish these capabilities. Encapsulation has two major impacts on metrics. The basic unit will no longer be the subprogram, but rather the object. We will have to modify our thinking on characterizing and estimating systems.

 

Two encapsulation measures in metrics suite are:

 

Attribute Hiding Factor (AHF)

 

The Attribute Hiding Factor measures the invisibilities of attributes in classes. The invisibility of an attribute is the percentage of the total classes from which the attribute is not visible.

 

Two encapsulation measures in metrics suite are:

 

Attribute Hiding Factor (AHF)

 

The Attribute Hiding Factor measures the invisibilities of attributes in classes. The invisibility of an attribute is the percentage of the total classes from which the attribute is not visible.

Information hiding is the suppression (or hiding) of details. The general idea is that we show only that information which is necessary to accomplish our immediate goals. There are degrees of information hiding, ranging from partially restricted visibility to total invisibility. Encapsulation and information hiding are not the same thing, e.g., an item can be encapsulated but may still be totally visible. Information hiding plays a direct role in such metrics as object coupling and the degree of information hiding.

Inheritance is a mechanism where one object acquires characteristics from one, or more, other objects. Single inheritance: an object may acquire characteristics directly from only one other object. Multiple inheritance: an object may acquire characteristics directly from two, or more, different objects. Inheritance decreases complexity by reducing the number of operations and operators. The two metrics used to measure the amount of inheritance are the depth and breadth of the inheritance hierarchy.

  • Depth of Inheritance Tree (DIT)
  • Number of Children (NOC)

 

In depth of inheritance tree (DIT) the depth of a class within the inheritance hierarchy is defined as the maximum length from the class node to the root/parent of the class hierarchy tree and is measured by the number of ancestor classes. The deeper the class is within the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior and, therefore, more fault-prone. Deeper trees require greater design complexity, since more methods and classes are involved. Interface changes within the tree must be reflected throughout the entire class tree and object instances. The deeper a particular tree is in a class, the greater potential reuse of inherited methods.

 

In number of children (NOC) this metric is the number of direct descendants (subclasses) for each class. Classes with large number of children are considered to be difficult to modify and usually require more testing because of the effects on changes on all the children. A class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible.

 

Abstraction is a mechanism for focusing on the essential details of a concept, while ignoring the inessential details. When moved to higher levels of abstraction we ignore more and more details, i.e., we provide a more general view of a concept or item. As we move to lower levels of abstraction, we introduce more details, i.e., we provide a more specific view of a concept or item. There are three commonly used views on the definition for “class,”: A class is a pattern, template, or a blueprint for a category of structurally identical items. The items created using the class are called instances. A class is a thing that consists of both a pattern and a mechanism for creating items based on that pattern. A class is the set of all items created using a specific pattern, i.e., the class is the set of all instances of that pattern.

A metaclass is a class whose instances are themselves classes. A metaclass is an abstraction of its instances. A parameterized class is a class in which some or all of the elements may be parameterized. New classes may be generated by instantiating a parameterized class with its required parameters. Metaclasses (usually) have run-time behavior, whereas parameterized classes (usually) do not have run-time behavior. The various Coupling

 

Cohesion Complexity

  • Weighted Methods/Class (WMC)

   Additional Measures

o Number of Classes

o Lines of Code

 

Coupling is a measure of interdependence of two objects. The Coupling Factor (CF) is evaluated as a fraction. The numerator represents the number of non-inheritance couplings and the denominator is the maximum number of couplings in a system. The stronger the coupling between software artifacts:

 

(i) The more difficult it is to understand individual artifacts, and hence to correctly maintain or enhance them

(ii) The larger the sensitivity of (unexpected) change and defect propagation effects across artifacts.

(iii) Consequently, the more testing required to achieve satisfactory reliability levels.`

Cohesion refers to how closely the operations in a class are related to each other.

Cohesion of a class is the degree to which the local methods are related to the local instance variables in the class. High cohesion indicates good class subdivision. Lack of cohesion or low cohesion increases complexity, thereby increasing the likelihood of errors.

Weighted Methods/Class (WMC) measures the complexity of an individual class. A class with more member functions than its peers is considered to be more complex and therefore more error prone. The larger the number of methods in a class, the greater the potential impact on children. Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse.

 

Number of Classes

 

If a comparison is made between projects with identical functionality, those projects with more classes are better abstracted.

 

Lines of Code

 

If a comparison is made between projects with identical functionality, those projects with fewer lines of code has superior design and requires less maintenance.

 

Summary

 

A software metric is a standard of measure of a degree to which a software system or process possesses some property. The availability of the software metric helps the project manager to control the various activities of the development life cycle and contributes to the overall objective of software quality. As objects are the fundamental building blocks for the object oriented programming rather than algorithm, the approach of software engineering metrics for the object oriented environment should be different from the functional programming environment. Different software engineering metrics for the object oriented development environment have been discussed here.