Axiomatic Properties

Weyuker[25] listed a set of properties (necessary but not sufficient) that are desired of a complexity measure for procedural programs. Although these properties have been criticized , Cherniavsky [4], they do provide a basis for some validation of complexity metrics short of using experimental data. As shown by Weyuker, with such properties it is possible to filter out measurements with undesirable properties.

We have not used all of the properties defined by Weyuker. These properties were defined for metrics intended to measure procedural programs and, as such, define some constraints that are not applicable to object-oriented software. In particular, assuming a single entry, single exit module does not address the object-oriented aggregation of methods into a class. Where there is an obvious mismatch between our goals and the properties we have omitted the property.

In the list of properties below, E, F and G represent classes and the complexity of E computed by an ideal measure is represented by . Classes can be concatenated either by inheritance or composition (collaboration). When a class F inherits from another class E, we depict the resulting subclass as Also, when a class E collaborates with another class F, the collaborating class is shown by . Two classes are said to be equivalent if they have the same behaviour for the classes.

• Property 1: .
  There exists two classes E and F such that the complexity of E is not equal to the complexity of F. The property requires that a measure should not produce the same value for every class. With our measure we can always come up with two classes with two different complexity values. We can always construct a class F which has a different number of data attributes or methods with different signatures from those in class E, such that the Visibility Component is different.

• Property 2: Let c be a nonnegative number. Then there are only finitely many classes of complexity c.
  A measure has to be sufficiently sensitive, and this property requires that a measure have a bounded range of values that it can assign. By the principle of number theory we can show that there is a finite combination of series whose sum is equal to . Each series in the combination represents a particular set of attribute Visibilities. Since there is a finite number of distinct series, the number of classes with the Visibility Component, c is finite.
• Property 3: There are distinct classes E and F such that, .
  A measure that assigns a unique value to every class is not much of a measure. It would go against the principle of measurements which requires that the number of objects that can be measured be greater than range of the values of the measure. Our measure clearly satisfies this property, since the Visibility Component does not depend on the types of the attributes. Given a class E, we can create a new class with a different number of attributes and methods having high visiblities so that the new class F has the same complexity value.
• Property 4: .
  There exist classes E and F such that E is equivalent to F but the complexity of E is not equal to the complexity of F. There are different implementations for the same functionality. Since our metric does not depend on data types, it independent on class implementations. Therefore this property is satisfied by our metric.

• Property 5: ).
  For all classes E and F, if F inherits from E then the complexity of is greater than or equal to the original complexity of F. Due to the inheritance, class F has access to all the public and protected data attributes of E. This increase in the implicit parameters of class F making the measure sensitive to inheritance.

Since our measure happens to satisfy all the above properties it can be considered to have passed a significant part of the theoretically validation process. The measure has been tested againt those axioms proposed by Weyuker that are applicable to both procedural and object-oriented software systems.