Enhancement in MOOD metrics

 The original MOOD metrics provided MHF and AHF to measure the level of encapsulation in the system. It was largely related to Information Hiding and it was not associated with other concepts of Encapsulation. Encapsulation and Information Hiding are not synonymous words but rather information hiding is only a part of larger concept encapsulation. Encapsulation can be defined using two words- Privacy and Unity. There can be a tradeoff between these two for the given class. Thus, MHF and AHF are not sufficient to measure the encapsulation for the given software system. In the newly proposed metric, we measure the two terms Privacy and Unity. Privacy can be measured by counting the number of private attributes inside a class. Unity can be measured by cohesion between the methods and attributes of the given class. If the class in a system is having more than around 75% of encapsulation then there is a specific use of encapsulation and there is no requirement to split the class.

 

Measurement of Class Unity (CU)       

       Class Unity measures the similarity between different methods and operations constrained in the class. If two methods are using the same attributes as their instances then these methods are considered as similar methods. The methods form a cluster-like structure where a cluster contains methods that are similar and methods in different clusters are not similar to ro each other. If there is only a single cluster then we can say that all the methods are similar to each other and the class has a high value of Class Unity(CU). Chidamber and Kemerer had introduced a new measure called “Lack of Cohesion in Methods”(LCOM). It measures cohesions by means of considering similar methods that use the same attributes.

For example, there is a class QUEUE wherein there are four attributes element, end, size, and bag. There are four methods Queue, Delete, Insert and Isempty. Now suppose element is used by Queue, Insert and Delete. The end is used by Queue, Delete, Insert, Isempty. Beg is used by Delete and Queue. Size is used by Queue, Delete, Insert. Now in this case Insert is similar to Delete, Isempty and Size. Delete is similar to Isempty, Size and Insert. Size is similar to Insert and Delete. Empty is similar to Insert and Delete. 

Measurement of Data Visibility(DV)

      It is concerned with how the data (Attribute and Methods) of a class is visible or directly accessible to other classes. If the attributes are private then they can not be accessible by other classes. Data Visibility generally uses a scale from 0 to 1 where 0 stands for private that fully hidden and 1 stand for the public. It is measured by the ratio of no. of classes that can access the data to the total number of classes in the system. The data visibility measurement is associated with the AHF metric. The final value of Dv is the average visibility of all the attributes.

Measurement of Encapsulation Factor (EF)

     To measure the level of encapsulation for the given class Encapsulation Factor (EF) metric is used. It considers both the aspects of a class that is attributes and methods. It is a function of both data hiding and cohesion metrics of a class.

         

The values of Class Unity(CU) and Data visibility(DV) ranges from 0 to 1. A class having CU and DV value 1 is considered as having 100% encapsulation. The point (1,1) is represented in the Figure is called optimal point.

Using the values of CU and DV we can measure the encapsulation for a given class. To find the value of the Encapsulation factor we have to find the distance of the given point from the optimal point. The equation for finding the value of EF is given by the following Figure.

        

                    

This value of EF shows the measure of encapsulation in the given class system. Generally, it is desirable to have Ef value close to 1. Let us consider two cases.

Best Case: 

Best case is possible when we have value of Encapsulation Factor as 1. Here the values of both CU and DV will be 1 and the point will be (1,1) which is considered as the optimal point.

Worst Case:

Worst case is possible when the value of EF is 0. Here the values of both CU and DV are 0. So we get point (0,0). This gives the minimum measure of encapsulation for the given class of the system.

Maintainability Estimation Model for Object-oriented software in the design phase

     In the software development life cycle, measuring the maintainability of the system in the early phase such as the design phase can reduce the huge amount of cost which manicured due to errors in the system because we can nullify the effect of it.

There is a model suggested which is helpful in estimating the maintainability of class diagrams of the system. The model is called MEMOOD (Maintainability Estimation Model for Object-Oriented software in the Design phase).

For UML class diagrams we need to understand the size and structural complexity metrics. These metrics are very useful for calculating the modifiability and understandability of the class diagram. 

The Maintainability Estimation Model can be represented by the following figure.

For making the model we have to go through the understating of correlation between these terms- Modifiability, Maintainability, and Understandability. The correlation metrics are defined as below.

  

From this Figure, we can say that Understandability and Modifiability are correlated to Maintainability whereas the correlation between Understandability and Modifiability is not that strong. Now we want to see how Maintainability is dependent on Understandability and Modifiability. We can make a linear model where Maintainability serves as a dependent variable whereas the other two serve as the independent variables. After calculating the values for the model we get out the linear model described by the following equation.

MOOD Metrics Suite

The MOOD metric set is used to measure the properties of the system in which the design of the system is according to the concepts of Object-Oriented Design that is Encapsulation,

Coupling, Inheritance, Information Hiding, Polymorphism.

The set contains six main metrics to measure the design of the system.

1.  Method Hiding Factor(MHF)  and Attribute Hiding  Factor(AHF)

To measure how the attributes and methods of one class are encapsulated, Method and Attribute hiding factors are being used. MHF and AHF show the average amount of how the members of a class are hidden in the system. MHF and AHF are 100% of all the members hid, nut in the real world it is next to impossible because a class should communicate with other classes to provide different functionality of the system. It is not possible if the members are hidden Generally hiding the increase in the following order. Public, Protected Friend, Friend, Protected Friend.

  If we have low MHF, then the methods are visible to almost every class. The methods are unprotected and can be subjected to changes by any class. The methods have a high tendency of reusability. In another case, if we have high MHF, then methods are not visible to many class and they can not understand the working of it. These methods can be used only by the class containing it and it has less tendency of reusability. The ideal range should be around 8% to 25%. In the case of AHF, the attributes of a class should be hidden from other classes so 100% is the ideal value of AHF. Generally, high value of AHF is advised.

  

2. Method Inheritance Factor  (MIF)  and Attribute Inheritance Factor(AIF)

        In Inheritance, the child or subclass inherits the properties (Attribute and Methods) of the parent or superclass. The extent to which these methods and attributes are inherited is defined by Method Inheritance Factor(MIF) and

Attribute Inheritance Factor(AIF).

A child class that inherits a large number of methods and attributes from its parent class contains a large value of MIF and AIF. As anything in a very small amount of very high amounts is harmful, the same case is with MIF and AIF. These values should be in a reasonable range. Generally, the range of MIF is between 20% to 80% and the range of AIf is between 0% and 48%. The low value of AHF shows that class should not inherit the attributes but rather the attributes should be private to the class. The child class can make some changes (override)  in the inherited methods.

3.  Polymorphism Factor (PF / POF)

       To measure the degree or extent of method overriding by the child class form the parent or superclass, Polymorphism Factor (PF) is used. In polymorphism, the child class can implement the method in a different way. The same method can be implemented in different ways in the child and parent class. It is defined by the ratio of an actual number of method overrides and the maximum number of total method overrides. To keep the code clean and clear and provide high quality we can use high PF but it increases the complexity of the system. Polymorphism factor is associated with method overriding, it is not associated with method overloading.

4. Coupling Factor (CF / COF) 

       If two or more clauses are related to each other by means of inheritance or aggregation or association then, in that case, these classes are said to be coupled. Many functionalities of the system can be done with the help of coupled classes. It is not advisable to have too many independent classes. The high value of Cf shows that the classes of the system are more inter-connected and inter-dependent. This leads to the problem that

Sometimes it is very hard to change or repair the system in case of any bugs or problem because the functionality in which the bug is, could be implemented by more than two classes and we have to make changes in all the related classes.

To measure the actual coupling between different classes Coupling Factor (CF) is used. It is the ratio of Actual coupling between different classes and maximum possible coupling can happen in the system. If a class can access the method and attributes of the second class then it is said that the first class is coupled with the second class. Generally, coupling happening due to inheritance is not considered while calculating the CF. The high value of coupling in the system leads to larger complexity. So it is advisable to have a high value of cohesion and low value of coupling. Good design architecture should contain less amount of coupling.

   MOOD2 METRICS 

          To enhance the original MOOD metrics, the MOOD2 metrics set was later added. The new suite provides the original six metrics along with that it provides new metrics - OHEF, AHEF, IIT, PPF.

1. Operation Hiding Effectiveness Factor(OHEF) and Attribute Hiding Effectiveness Factor(AHEF)

         OHEF and AHEF are better and improved versions of  MHF and AHF. MHF measures the level of method hiding in the system whereas OHEF measures how good the hiding is and how well it is successfully implemented. It measures the goodness of the scope of the operation of the method of the class.

AHF measures the level of attribute hiding in the system whereas AHEF measures how the attributes are hiding and how successful the attribute hiding is. These two factors are used widely for the system that imposed the object-oriented paradigm.

 2. Internal Inheritance Factor (IIF)

          Internal Inheritance Factor(IIF) is the improvised version of

Method/ Attribute Inheritance Factor(MIF/AIF).  To measure the internal inheritance of the software system IIF is being used. Internal inheritance means classes are inherited by the classes which are present in the given system.

3. Parametric polymorphism Factor (PPF)

       It is an improvised version of the PF. It is defined as the ratio of  Parametrized classes in the system to Toal no of classes in the system. A parameterized class can be considered as a generic class.

Introduction to MOOD metrics for Software Engineering

In today's world, the requirement for the maintainability of the software system is very high. In the phase of software design and development, the measurement of software in an object-oriented system gives us the maintenance effort. We can define the maintainability of software is how it can be corrected, understood or enhanced. The basic aim of any software project is that the cost of maintenance should be low after the product is being completed. Doing measurement of maintenance in the design or development phase reduces the overall cost fIn today's world the requirement for the maintainability of a software system is very high. In the phase of software design and development, the measurement of software in an object-oriented system gives us the maintenance effort. We can define the maintainability of software is how it can be corrected, understood or enhanced. The basic aim of any software project is that the cost of maintenance should be low after the product is being completed. Doing the measurement of maintenance in the design or development phase reduces the overall cost for maintenance because the error cost decreases.

The maintainability can also be defined as how it is easy to modify, correct, improve performance or adapt to a changing environment for any software component or system. So many good developers prefer to measure the characteristics of the system in order to make sure that the requirements are completed or not or the quality of the design is high or not or the code is correct and can be tested or not.or maintenance because the error cost decreases.

The MOOD metrics were introduced by Fernando Brito e Abreu. These metrics are designed to give a summary of the whole object-oriented project. There are 6 metrics contained in MOOD. The MOOD2 metrics were later added to the list. These metrics are so much helpful for the projects which have large use of object-oriented programming. These metrics are useful for the entire project rather than individual classes.

Object-Oriented Concepts and Metrics

Polymorphism

Polymorphism is the capacity of a message to take numerous frames relying on the message sender. The task to be called to answer the message might be chosen at compile-time or at run-time. So polymorphism can be static (incorporate time) or dynamic (run time). Additionally, polymorphism can be ad-hoc or all-inclusive. On the off chance that distinctive classes (may not be from the same pecking order) utilize only a similar name for a comparative sort of activity, it is called ad-hoc polymorphism. Be that as it may, if classes in a similar chain of command execute a similar task in various ways, it is known as general polymorphism. Usage of activity may fluctuate along the chain of command of classes. At the framework level, the Polymorphism Factor (PF) metric from the MOOD metric set measures the polymorphic conduct of classes taken together.

Inheritance

Inheritance shows how two or more clauses are related to each other. Here one class is derived from the other class. The new class is called a child or derived or subclass and the class from which it is inherited is called a parent or super or base class. The subclass contains all the functionality of the parent class and also it contains some new functionality that differentiates it from the parent class. There are mainly two metrics that use inheritance, Attribute Inheritance Factor(AIF) and Method Inheritance Factor(MIF).

Information Hiding

   In a system that uses object-oriented concepts, encapsulations generally mean that we group the methods with the data structure. It is not advisable that complex system parts should depend on one another. The service of the system should be accessible to client by means of message passing. That is the client should not know everything about the internal structure of the system architecture. This leads to information hiding. With the combination of Information Hiding and Encapsulation, we can get a more flexible, stable system that can be accommodated easily with different types of changes. To measure the Information Hiding capacity to the degree of the system we generally use two metrics, Method Hiding Factor(MHF) and Attribute Hiding Factor(AHF). 

 Coupling

     In every software system, the system contains many components that perform specific tasks. It is not practically feasible that all the components work in isolation. All the components should work along with other components to support the behavior and function of the software system. In the object-oriented paradigm, different classes depend on one another to provide specific workings of the system. If two classes are highly depended on each other then they are said to be tightly coupled and if the classes are not highly depended on each other then they are said to be loosely coupled. The classes which are tightly coupled are somewhat hard to understand because to understand the whole functionality you have to study all the related classes. Whereas, understanding the working of loosely coupled classes is comparatively easy because they contain the whole functionality by themselves.

These loosely coupled classes can be used again, so they provide reusability and maintainability. These classes can easily undergo changes and we don’t have to make changes in many classes. We should avoid the system with large number of class dependencies because this make the system fragile and weak. To measure the coupling between the classes Coupling Factor (CF)  metric is being used at the system level.