Includes all operations in the class that are explicitly modeled (overriding operations, constructors, destructors), regardless of their visibility, owner scope (class-scope, i.e., static), or whether they are abstract or not. Inherited operations are not counted.

• Also known as: WMC (Weighted method complexity) where each operation is assigned unity complexity [CK94].
• Also known as: NM (Number of Methods) [LK94].

Same as metric NumOps, but only counts operations with public visibility. Measures the size of the class in terms of its public interface.

• Also known as: NPM (Number of Public Methods) [LK94].

Note that this metric does not always yield accurate results. For example, an operation settleAccount will be counted as setter method.

• See also: Getters.

Note that this metric does not always yield accurate results. For example, an operation isolateNode will be counted as getter method.

• See also: Setters.

Measures how deeply a class is nested within other classes. Classes not defined in the context of another class have nesting level 0, their inner classes have nesting level 1, etc. Nesting levels deeper than 1 are unusual; an excessive nesting structure is difficult to understand, and should be revised.

This only counts direct interface realization links from the class to the interface. For example, if a class C implements an interface I, which extends some other interfaces, only interface I will be counted, but not the interfaces that I extends (even though class c implements those interfaces, too).

Similar to export coupling, NOC indicates the potential influence a class has on the design. If a class has a large number of children, it may require more testing of the methods in that class. A large number of child classes may indicate improper abstraction of the parent class.

• Defined in [CK94].

Counts the number of children of the class, their children, and so on.

• See also: NOC (Number of Children).
• Suggested in [LC94] and [TSM92].

Counts the number of parents of the class, their parents, and so on. If multiple inheritance is not used, the metric yields the same values as DIT.

• Suggested in [LC94] and [TSM92].

This is calculated as the longest path from the class to the root of the inheritance tree. The DIT for a class that has no parents is 0.

Classes with high DIT inherit from many classes and thus are more difficult to understand. Also, classes with high DIT may not be proper specializations of all of their ancestor classes.

• Defined in [CK94].

• Defined in [TSM92].
• See also: NOC (Number of Children).

This is calculated as the sum of metric NumOps taken over all ancestor classes of the class.

• Also known as NMI [LK94].
• See also: DIT.

This is calculated as the sum of metric NumAttr taken over all ancestor classes of the class.

• Loosely based on AIF in [AGE95].

This metric counts outgoing plain UML dependencies and usage dependencies (shown as dashed arrows in class diagrams, usage with 'use' stereotype).

This metric counts incoming plain UML dependencies and usage dependencies (shown as dashed arrows in class diagrams, usage with 'use' stereotype).

For instance, for a class that is defined in a package p, this counts only associations with classes, interfaces, etc. in the same package p. Such associations are encouraged, because they do not cross the package boundary, and contribute to the cohesion of the package.

This metric does not distinguish plain, aggregate, or composite associations, as well as incoming, outgoing, or bidirectional associations; all such associations are counted.

For instance, for a class that is defined in a package p, this metric only counts associations with model elements

• in p itself,
• in packages that p contains (subpackages, sub-subpackages etc. of p),
• in packages that contain p (packages of which p is a subpackage, sub-subpackage etc).

• Note: Like metric NumAssEl_ssc, direction and aggregation of the associations are ignored.

For a class that is defined in a package p, this counts only associations with model elements in packages that neither contain p nor are contained by p. These are the least desirable associations, because they couple otherwise unrelated packages. Such associations cannot be avoided, but their use should be minimized.

• Note: Like metric NumAssEl_ssc, direction and aggregation of the associations are ignored.

This is the number of attributes in other classes that have this class as their type.

• Version of: OAEC+AAEC in [BDM97].

• Version of: OAIC+AAIC in [BDM97].
• Also known as: DAC (data abstraction coupling) [LH93].

This is the number of parameters defined outside this class, that have this class as their type.

• Version of: OMEC+AMEC in [BDM97].

• Version of: OMIC+AMIC in [BDM97].

Similar to export coupling, the more instances of the class there are, the larger the role of the class in the system.

Similar to export coupling, the more lifelines there are of the class, the larger the role of the class in the system.

Counts the number of messages that instances of this class send to instances of other classes, or unclassified instances.

• Version of OMMIC+AMMIC in [BDM97].

Counts the number of messages that instances of this class receive from instances of other classes or unclassified instances.

• Version of OMMEC+AMMEC in [BDM97].

Counts the number of messages that instances of this class send to themselves or to other instances of the same class.

• Version of ICH in [LLW95].