Object-Oriented Analysis and Design of software provide many benefits such as reusability, decomposition of problem into easily understood object and the aiding of future modifications. But the OOAD software development life cycle is not easier than the typical procedural approach. Therefore, it is necessary to provide dependable guidelines that one may follow to help ensure good OO programming practices and write reliable code. Object-Oriented programming metrics is an ascpect to be considered. Metrics to be a set of standards against which one can measure the effectiveness of Object-Oriented Analysis techniques in the design of a system.
OO metrics which can be applied to analyze source code as an indicator of quality attributes. The source code could be any OO language.
Metrics for OO Software Development Environments
In his master's thesis Morris [Morris 1989] made some important observations on OO code and proposed candidate metrics for productivity measurement :Methods per Class
Average number of methods per object class = Total number of methods / Total number of object classes
- A larger number of methods per object class complicates testing due to the increased object size and complexity
- if the number of methods per object class gets too large extensibility will be hard
- A large number of methods per object class may be desirable because subclasses tend to inherit a larger number of methods from superclasses and this increases code reuse.
Inharitance tree depth = max ( inheritance tree path length )
Degree of Coupling Between Objects
- Inheritance tree depth is likely to be more favorable than breadth in terms of reusability via inheritance. Deeper inheritance trees would seem to promote greater method sharing than would broad trees
- A deep inheritance tree may be more difficult to test than a broad one
- Comprehensibility may be diminished with a large number inheritance layers
Average number of uses dependencies per object = total number of arcs / total number of objects
arcs = max ( number of uses arcs ) - in an object uses network
arcs - attached to any single object in a uses network
Degree of Cohesion of Objects
- A higher degree of coupling between objects complicates application maintenance because object interconnections and interactions are more complex.
- The higher the degree of uncoupled object the more objects will suitable for reuse within the same applications and within other applications.
- Uncoupled objects should be easier to augment than those with a high degree of 'uses' dependencies, due to the lower degree of interaction.
- Testability is likely to degrade with a more highly coupled system of objects.
- Object interaction complexity associated with coupling can lead to increased error generation during development.
Degree of Cohesion of Objects = Total Fan-in for All Objects / Total No. of Objects
Object Library Effectiveness
- Low cohesion is likely to produce a higher degree of errors in the development process. Low cohesion adds complexity which can translate into a reduction in application reliability.
- Objects which are less dependent on other objects for data are likely to be more reusable.
Average number = Total Number of Object Reuses / Total Number of Library Objects
- If objects are actually being designed to be reusable beyond a single application, then the effects should appear in object library usage statistics.
Factoring Effectiveness = Number of Unique Methods / Total Number of Methods
Degree of Reuse of Inheritance Methods
- Highly factored applications are more reliable for reasons similar to those which argue that such applications are more maintainable. The smaller the number of implementation locations for the average task, the less likely that errors were made during coding
- The more highly factored an inheritance hierarchy is the greater degree to which method reuse occurs
- The more highly factored an apllication is, the smaller the number of implementation locations for the average method
Percent of Potential Method Uses Actually Reused (PP):
PP = ( Total Number of Actual Method Uses / Total Number of Potential Method Uses ) x 100
Percent of Potential Method Uses Overridden (PM):
PM = ( Total Number of Methods overrridden / Total Number of Potential Method Uses ) x 100
Average Method Complexity
- Defining methods in such a way that they can be reused via inheritance does not guarantee that those methods are actually reused.
Average method complexity = Sum of the cyclomatic complexity of all Methods / Total number of application methods
- More complex methods are likely to be more difficult to maintain.
- Greater method complexity is likely to lead to a lower degree of overall application comprehensibility.
- Greater method complexity is likely to adversely affect application reliability.
- More complex methods are likely to be more difficult to test.
Application granularity = total number of objects / total function points
- One of the goals of object-oriented design is finer granularity. The purpose is to achieve a greater level of abstraction than possible with data/procedures-oriented design.
- An application constructed with more finely granular objects (i.e. a lower number of functions per object) is likely to be more easily maintained because objects should be smaller and less complex.
- More finely granular objects should also be more reusable. ... Therefore, each object's behavior should be more easily understood and analyzed.
Chidamber & Kemerer's Metics Suite[Chidamber and Kemerer]
Chidamber and Kemerer's metrics suite for OO Design is the deepest reasearch in OO metrics investigation. They have defined six metrics for the OO design.
Weighted Methods per Class ( WMC )
It is defined as the sum of the complexities of all methods of a class.
- The number of methods and the complexity of methods involved is a predictor of how much time and effort is required to develop and maintain the class.
- The larger the number of methods in a class the greater the potential impact on children, since children will inherit all the methods defined in the class.
- Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse.
Depth of Inheritance Tree (DIT)
It is defined as the maximum length from the node to the root of the tree.
- The deeper a class is in the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior.
- Deeper trees constitute greater design complexity, since more methods and clases are involved.
- The deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods.
Number of Children (NOC)
It is defined as the number of immediate subclasses.
- The greater the number of children, the greater the reuse, since inheritance is a form of reuse.
- The greater the number of children, the greater the likelihood of improper abstraction of the parent class. If a class has a large number of children, it may be a case of misuse of subclassing.
- The number of children gives an idea of 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.
Coupling between object classes (CBO)
It is defined as the count of the classes to which this class is coupled. Coupling is defined as : Two classes are coupled when methods declared in one class use methods or instance variables of the other class. [Chidamber and Kemerer 1994]
- Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application.
- In order to improve modularity and promote encapsulation, inter-object class couples should be kept to a minimum. The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult.
- A measure of coupling is useful to determine how complex the testing of various parts of a design are likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be.
Response For a Class (RFC)
It is defined as number of methods in the set of all methods that can be invoked in response to a message sent to an object of a class.
- If a large number of methods can be invoked in response to a message, the testing and debugging of the class becomes more complicated since it requires a greater level of understanding on the part of the tester.
- The larger the number of methods that can be invoked from a class, the greater the complexity of the class.
- A worst case value for possible responses will assist in appropriate allocation of testing time.
Lack of Cohesion in Methods (LCOM)
It is defined as the number of different methods within a class that reference a given instance variable.
- Cohesiveness of methods within a class is desirable, since it promotes encapsulation.
- Lack of cohesion implies classes should probably be split into two or more subclasses.
- Any measure of disparateness of methods helps identify flaws in the design of classes.
- Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process.
- They appeared from the nature from the OO approach
- NOC and RFC metrics give some idea as to budgeting for testing that class.
- Measuring comlexity of a class is subject to bias
- They cannot give a good size and effort estimation of software
- These metrics seem only to bring the design phase into play, and does not provide adequate coverage in terms of planning
MOOD ( Metrics for Object Oriented Design )
The MOOD metrics set refers to a basic structural mechanism of the OO paradigm as encapsulation ( MHF and AHF ), inheritance ( MIF and AIF ), polymorphishm ( PF ) , message-passing ( CF ) and are expressed as quotients. The set includes the following metrics :
Method Hiding Factor ( MHF )
MHF is defined as the ratio of the sum of the invisibilities of all methods defined in all classes to the total number of methods defined in the system under consideration.
The invisibility of a method is the percentage of the total classes from which this method is not visible.
note : inherited methods not considered.
Attribute Hiding Factor ( AHF )
AHF is defined as the ratio of the sum of the invisibilities of all attributes defined in all classes to the total number of attributes defined in the system under consideration.
Method Inheritance Factor ( MIF )
MIF is defined as the ratio of the sum of the inherited methods in all classes of the system under consideration to the total number of available methods ( locally defined plus inherited) for all classes.
Attribute Inheritance Factor ( AIF )
AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under consideration to the total number of available attributes ( locally defined plus inherited ) for all classes.
Polymorphism Factor ( PF )
PF is defined as the ratio of the actual number of possible different polymorphic situation for class Ci to the maximum number of possible distinct polymorphic situations for class Ci.
Coupling Factor ( CF )
CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance.
In the MOOD Project Home Page you can find papers, and MOOD estimation tools about MOOD.
Estimating With Objects - Watts S. Humphrey's[Humprey 1996]