Tuesday, November 12, 2019

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. 


No comments:

Post a Comment