MOOD Factors to Assess a Java Program

Application quality is critical to the development of software systems, especially large-scale ones. High quality software would reduce the cost of software maintenance, and it enhances the potential software reuse.

In order to measure the software quality more quantitatively and objectively, software metrics (MOOD) give impression to be a powerful and effective methodology that decide a grade to an object-oriented application. So, in this section, we will discuss the mood factors to assess an object-oriented application.

MOOD stands for Matrices for Object Oriented Design. It describes the characteristics of an object-oriented application or program. It is used to evaluate a grade of Java program. MOOD factors include the following six software quality indicators or metrices:

• Method Hiding Factor (MHF)
• Attribute Hiding Factor (AHF)
• Method Inheritance Factor (MIF)
• Attribute Inheritance Factor (AIF)
• Coupling Factor (COF)
• Polymorphism Factor (POF)

Information Hiding factors

MHF and AHF are measures of the use of the information-hiding concept supported by the encapsulation mechanism. Information hiding should be used to:

1. Cope with complexity by looking at complex components such as black boxes.
2. Reduce "side-effects" provoked by implementation refinement.
3. Support a top-down approach.
4. Test and integrate systems incrementally.

Method Hiding Factor (MHF)

MHF can be calculates by using the following mathematical formula:

Where,

M_h(C_i) = hidden Methods in class C_i

M_d(C_i) = M_v(C_i) + M_h(C_i): Methods defined in C_i

M_v(Ci): visible Methods in class C_i

TC: Total number of Classes

The visible methods measure the class functionality. Enhancing the overall functionality of the class, reduces the MHF. In order to implement this functionality, a top down approach must be adopted. It means that the class implementation must be a step by step decomposition process so that we can add more and more detail in hidden methods that results in incremented MHF.

A very low MHF value denotes implementation of insufficiently abstracted methods. Conversely, a high MHF value denotes very little functionality. Therefore, the MHF values must lies within an interval 2,3, and 4.

Attribute Hiding Factors (AHF)

AHF can be calculates by using the following mathematical formula:

Where,

A_h(C_i) = hidden attributes in class C_i

A_d(C_i) = A_v(C_i) + A_h(C_i): attributes defined in C_i

A_v(Ci): visible attributes in class C_i

TC: Total number of classes

AHF is a measure of the use of the information hiding concept supported by the encapsulation mechanism. Information hiding allows coping with complexity by turning complex components into black boxes. AHF should be used as much as possible. Ideally all attributes would be hidden, thus being only accessed by the corresponding class methods. Very low values of AHF should trigger the designers' attention. In general, as AHF increases, the complexity of the program decreases 2,3, and 4.

Inheritance Factors

Both MIF and AIF are measures of inheritance. This is a mechanism for expressing similarity among classes that allows for the portrayal of generalization and specialization relations, and a simplification of the definition of inheriting classes by means of reuse [2,3,4,5].

Method Inheritance Factor (MIF)

MIF can be calculated by using the following mathematical formula:

Where,

M_i: inherited methods

M_a(C_i) = M_d(C_i) + M_i(C_i): attributes defined in C_i

M_d(Ci): defined methods

TC: Total number of classes

At first sight, we might be tempted to think that inheritance should be used extensively. However, the composition of several inheritance relations builds a directed acyclic graph (inheritance hierarchy tree), whose depth and width make understandability and testability fade away quickly [1,2,3,4].

Attribute Inheritance Factor (AIF)

AIF can be calculated by using the following mathematical formula:

Where,

A_h(C_i) = hidden attributes in class C_i

A_d(C_i) = A_v(C_i) + A_h(C_i): attributes defined in C_i

A_v(Ci): visible attributes in class C_i

TC: Total number of classes

Coupling Factor (COF)

It measures the coupling between classes.

COF can be calculated by using the following mathematical formula:

Where,

is_client(C_c,C_s) =| 1 if (C_c⇒C_s)^(C_c≠C_s) , 0 otherwise

TC: It denotes the total number of classes.

The client-supplier relation, represented by C_c ⇒ C_s, means that C_c (client class) contains at least one noninheritance reference to a feature (method or attribute) of class C_s (supplier class). The COF numerator represents the actual number of coupling not imputable to inheritance 2, 3, 4, and 6.

It is desirable that classes communicate with as few other classes as possible, and that they exchange as little information as possible. Coupling relations increase complexity, reduce encapsulation and potential reuse, and limit understandability and maintainability. Also, coupling in software systems has a strong negative impact on software quality, and therefore should be kept to the minimum during the design phase. However, for a given application, classes must cooperate to deliver some kind of functionality. Therefore, COF is expected to be lower bounded 2, 3, and 4.

Polymorphism Factor (POF)

Polymorphism means having the ability to take several forms. In OO systems, polymorphism allows the implementation of a given operation to be dependent on the object that "contains" the operation 2, 3, 4, and 6.

Where,

M_o(C_i): overriding Methods in class C_i

M_n(Ci): new Methods in class C_i

D_C(C_i): number of Descendants of Class C_i (derived classes)

TC: Total number of Classes

The POF numerator represents the actual number of possible different polymorphic situations. A given message sent to class C_i can be bound, statistically or dynamically, to a named method implementation which may have as many shapes as the number of times this same method is overridden (in C_i descendants) 2, 3, 4.

Polymorphism arises from inheritance. Binding (usually at run time) a common message call to one of several classes (in the same hierarchy) is supposed to reduce complexity and to allow refinement of the class hierarchy without side effects. On the other hand, to debug such a hierarchy, by tracing the control flow, this same polymorphism would make the job harder. Therefore, polymorphism ought to be bounded within a certain range 2, 3, 4.

Evaluation of MOOD Factors

The grade awarded to an object-oriented program depends on the following table that is based on experiments.

The final grade is computed by using the following steps:

Step 1: For all the indicators do the following:

IF the indicator value is found within the specified range, THEN GRADE = 100%

ELSE IF the indicator value is located in the tolerance range, THEN 60%≤GRADE by using interpolation.

ELSE, the indicator outside the tolerance range, then GRADE<60% by using interpolation formula and the system should trigger the programmer's attention to a problem.

Where,

GRADE [i]: the grade for the indicators i.

W[i]: weight value assigned to the indicator to reflect its importance.

n: It is the number of factors, n=6.

Where,

FINAL GRADE: It represents the final grade of the evacuated object-oriented program [0:100].

TW: It represents the total weight that can be computed by using the following formula:

Where,

n: the total number of indicators, n=6.

W(Fi): the weight for indicator i.

The grade of each indicator ranges from 0% to 100%. Each indicator is assigned a weight to reflect its importance. The classification of the six indicators is shown in the following table. This table is produced from reported study 2, 3, 4, 5, and 6.

Let's consider the following design patterns and evaluate their grade using MOOD factors.

Let's evaluate the grade for the above design pattern.

Base on the above evaluation, we have recommended the following:

• Hide more methods.
• The number of inherited methods should be increased.
• The use of polymorphism must be reduced.

We observe that each MOOD factor is associated with basic structural mechanisms of the object-oriented model. It is the mechanism that enables some recommendations for designers.

The interval of each MOOD factor has been altered that is based on experimental results, to be fit in the evaluation of Java Programs. The weight factor reflects the importance of each characteristic.