BACKGROUND
The present invention relates to object-oriented programming. More specifically, it relates to assessing the modularity of an object-oriented program.
A software application built using object-oriented programming techniques has modular architecture. Thus, the software application includes one or more modules that implement various functionalities by defining classes, objects, methods, etc. According to the best programming practices, each module should be cohesive and the degree of coupling among the modules should be minimum. Coupling of a module is determined by the degree of dependency the module has on other modules of the software application. Cohesion associated with the module is determined by the degree of similarity between the functions the module performs. Coupling and cohesion determine the degree of modularization of the software application. A low degree of coupling and a high degree of cohesiveness enable the programmer to easily maintain and extend the software application. Extending the software application is required to update/change the software application according to the changing requirements of users. For example, a banking enterprise may wish to offer additional features to the users of net banking. In this case, the programmers of the net banking software need to extend/change the software to incorporate the additional features.
As the size of the object oriented program of the software application grows, the modules become interdependent. Various properties of object-oriented programming result in this interdependence, such as a module extending the class of another module, a class in a module using an instance of a class defined in another module as an attribute or a parameter in method definition, and a method in a class of a module calling a method defined in another module. Due to the interdependence, making a change in a module affects the functionalities of the other dependent modules. Therefore, corresponding changes need to be made in all the dependent modules. As a result, such a software application is difficult to extend and maintain. Consequently, it is important to monitor the degree of modularization for the software application.

Currently, methods are available to determine the degree of modularization for non-object-oriented systems such as procedural systems. These metrics do not take into account the interdependence induced among the modules due to the properties of object-oriented programming, such as inheritance, polymorphism, encapsulation, state access, and containment. Further, there are methods available for measuring the degree of modularization associated with a property of the object-oriented program. However, the degree of modularization is calculated only at the level of classes. Therefore, for large object-oriented programs consisting of hundreds of classes, calculating modularity at the level of classes for each property is not feasible.
In light of the above discussion, there is a need for a method and system for quantitatively measuring the degree of modularization for a software application built on the object-oriented architecture.
SUMMARY
An object of the invention is to assess the modularity of an object-oriented program.
Another object of the invention is to graphically represent the results of the assessment of the modularity.
The invention provides a process, system and computer program product for assessing the modularity of an object-oriented program. A plurality of properties is associated with the object-oriented program. The object-oriented program includes a plurality of modules. At least one module of the plurality of modules includes one or more classes and one or more Application Programming Interfaces (APIs). Further, at least one class of the one or more classes includes one or more attributes and one or more methods. At least one metric is calculated for each of the at least one module of the plurality of modules. Each metric of the at least one metric is associated with one property of the plurality of properties associated with the object-oriented program. The property associated with the each metric is at least one of API-based coupling of the at least one module, inheritance-based coupling of the at least one module, association-

i J
based coupling of the at least one module, state access-based coupling of the at least one module, size of the at least one module, and use of the at least one module.
The at least one calculated metric is analyzed, based on a predefined threshold value. Based on the analysis of the at least one calculated metric, graphical reports are generated.
The process, system and computer program product described above have a number of advantages. The process enables calculation of metrics to quantitatively measure the modularity of the object-oriented program. Further, these metrics are calculated at the level of modules and based on various properties of the object-oriented program, such as interdependence induced among the modules due to properties such as inheritance, polymorphism, abstraction and containment. Since the metrics are calculated at the level of modules, the present invention overcomes the disadvantages of calculating the metrics at the level of classes. Furthermore, the system displays the calculated values of the metrics in the form of graphical reports to the users. These graphical reports enable the users to monitor the modularity of the object-oriented program and identify the reasons for degradation in modularity.
BRIEF DESCRIPTION OF THE DRAWINGS
The various embodiments of the invention will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the invention, wherein like designations denote like elements, and in which:
FIG. 1 Is a flow diagram illustrating the process for assessing the modularity of an object-oriented program, in accordance with an embodiment of the invention;
FIG. 2 is an exemplary graphical report illustrating the results of the assessment of the modularity of the object-oriented program, in accordance with an embodiment of the invention; and
FIG. 3 is a block diagram of a system configured for assessing the modularity of the object-oriented program, in accordance with an embodiment of the invention.

I
DESCRIPTION OF VARIOUS EMBODIMENTS
The invention describes a process, system and computer program product for assessing the modularity of an object-oriented program. The process includes calculating metrics based on a plurality of properties associated with the object-oriented program. The calculated metrics are presented to the users in the form of graphical reports. The process for assessing the modularity of the object-oriented program has been described below in detail.
FIG. 1 is a flow diagram illustrating a process for assessing the modularity of an object-oriented program. The object-oriented program is associated with a plurality of properties. The plurality of properties includes, but is not limited to, inheritance, polymorphism, abstraction, containment, state access, use, size, association, plugin extension and encapsulation. Further, the object-oriented program includes a plurality of modules. Furthermore, at least one module of the plurality of modules includes one or more classes and one or more Application Programming Interfaces (APIs). In addition, at least one class of the one or more classes includes one or more methods and one or more attributes.
At step 102, at least one metric is calculated for each of the at least one module. Each of the at least one metric is calculated based on a property of the plurality of properties. In an embodiment of the invention, the property considered for the calculation of the metric is one of API-based coupling of the module, inheritance-based coupling of the module, association-based coupling of the module, state access-based coupling of the module, size of the module, and use of the one module. The metric associated with each property is a quantitative measure of the modularity of the module. It may be apparent to any person skilled in the art that calculating the metric for each of the modules of the object-oriented program facilitates assessment of the modularity of the object-oriented program.
The modularity of the object-oriented program is determined by coupling among the plurality of rnodules and cohesion associated with each module of the plurality of modules. Coupling of the module is determined by the degree of dependency the

module has on the other modules of the plurality of modules. Cohesion associated with, the module is determined by the degree of similarity between the various functions performed by the module. An ideal object-oriented program has a low degree of coupling and a high degree of cohesion.
According to the various embodiments of the invention, the metric calculated, based on each property of the object-oriented program, is as given below:
1 ■ Metrics associated with API-based coupling of the module
An API of the module determines the way the module interacts with the other modules of the object-oriented program. The module includes one or more APIs that can be broadly categorized as Sen/ice-APIs (S-APIs) and Extension-APIs (E-APIs).
The S-APIs declare methods that should be called by the other modules of the object-oriented program. The E-APIs of the module declare abstract classes and abstract methods of the module. The E-APIs facilitate adding a new functionality to the module by using a plug-in. The plug-in adds the new functionality to the module by accessing these abstract classes and methods without requiring access to the source code of the module.
In an embodiment of the present invention, there are four metrics associated with the API-based coupling of the module. They are Module Interaction Index (Mil), Non-API Closedness Index (NC). Not Programming Interface Index (NPII) and API Cohesiveness and Segregation (APIU).
The calculation of these metrics has been further explained below in detail.
a. Module Interaction Index (M\\)
In an embodiment of the invention, the metric associated with the API-based coupling of the module represents the degree of interaction between the module and the other modules through the methods declared in the APIs. The metric is calculated, based on a first set of external calls and a second set of external calls. The first set of external calls includes external calls made to a subset of the one or more methods of the module. The subset of methods includes ail the methods declared in tlie APIs of the module. The external calls originate from classes or methods that reside outside the

module. Similarly, the second set of external calls includes external calls made to any or the one or methods of the module. Further, the second set of external calls includes external calls made to the methods of the other classes of the one or more classes. In an ideal object-oriented program, the number of external calls in the first set of external calls is equal to the number of external calls in the second set of external calls.
In an embodiment of the present invention, the first set of external calls made to the methods declared in an API, denoted as fAPI /) of the one or more APIs of the module p, is denoted as ExtCallRel(i). All the APIs of the module p are denoted as l(p).


i
Where, P denotes a set of all the modules defined in the object-oriented program.
The calculated value for MU(S) lies in the range of 0 to 1. In the ideal state, the value of MH(S) is 1, which indicates that all the methods of the object-oriented program are called through their corresponding APIs. A value of 0 for the metric M}l(S) indicates that the object oriented program has poor inter-module interaction.
b. Non-API Closedness Index (NO
In an embodiment of the present invention, the metric associated w/ith the APi-based coupling of the module represents the non-API closedness of the module. The non-API closedness of the module is based on a set of pubic methods defined in the module. Further, the non-API closedness is based on a set of API methods and a set of non-API methods. The set of API methods includes the public methods of the set of public methods declared in the one or more APIs of the module. The set of non-API methods includes the public methods of the set of public methods not called by the other modules of the object-oriented program. In the ideal event, only the API methods are called by the other modules of the object-oriented program. In other words, the number of methods in the set of non-API methods is equal to the difference between the number of methods in the set of public methods and the number of methods in the set of API methods.
In an embodiment of the present invention, for a module p having one or more APIs denoted as the set l(p), the set of non-API methods is denoted as M„a(p), and the set of public methods defined in the module p is denoted by Mpub(p)- For an API / of the set l{p), the set of methods declared in the API / is denoted by M(f).
The metric associated with the API-based coupling of the module p representing the non-API closedness of the module p is denoted as NC(p). The metric representing the overall non-API closedness of the object-oriented program is denoted as NC(S).

I
Where,
P denotes a set of all the modules defined in the object-oriented program, and
l(p) denotes a set of APIs for module p.
The value of NC(S} lies in the range of 0 to 1. In the ideal state, the value of the metric is 1, which indicates that the methods of the set of non-API methods are not being called by the other modules of the object-oriented program.
There is a possibility that all the public methods Mpub(p) of module p are declared in the APIs. In such a case, the value of the metric is determined by the size of the object-oriented program. If the object-oriented program is small and a programmer considers all the public methods to constitute the API of the module p, NC(p) has a value 1 when both the numerator and the denominator are 0. On the other hand, in the case of large object-oriented programs for which only a subset of the public methods Mpub(p) constitutes the APIs of module p, NC(p) is 0 when the denominator is 0.
c. Not Programming Interface Index (NPII)
The module defines one or more classes that form one or more inheritance hierarchies. Each Inheritance hierarchy has a root interface. In an ideal case, when a module A acts as a client to module B, module A accesses the functionalities of module B only through the root interfaces of the inheritance hierarchies of module B. The root interfaces include abstract classes and abstract methods. An abstract class is a class that cannot be instantiated but can be extended through inheritance. An abstract method is a method declared in the abstract class without an implementation. The abstract method can be overridden by a method defined in the extending class of the abstract

class. This method is known as a concrete method. The concrete method provides the implementation of the abstract method.
In an embodiment of the present invention, the metric associated w/ith the API-based coupling of the module is based on a set of abstract methods and a set of concrete methods. Each abstract method is called by at least one method of the one or more methods of the module. Each concrete method is called by at least one method of the one or more methods of the module and defined by a class, vi/hich is a part of an inheritance hierarchy.



Where, DoesOvride(m') is a predicate, which is true when method m' overrides a method of the object-oriented program, and
Doeslmpl(m') is a predicate, which is true when method m' is an implementation of an abstract method of the object-oriented program.
The metrics representing the extent of non-programming to interfaces for a module p, and the object-oriented program are denoted by Nll(p) and NII(S), respectively.

Where, M{p) denotes a set of all the methods defined in module p, and
P' denotes a set of all the modules defined in the object-oriented program.
The value of NPII ranges from 0 tol. The value of 1 indicates that only the abstract methods defined in the root interfaces of the inheritance hierarchies of the modules are accessed by other modules.

d. API Cohesiveness and Segregation (APIUi
In an embodiment of the invention, the metric associated with the API-based coupling of the module measures the extent to which the S-APIs of the module are cohesive and segregated. The S-APIs must be cohesive with respect to their functionalities and segregated from the other S-APIs of the module with respect to their use. The metric is based on a set of modules and a set of methods. Each module of the set of modules calls at least one method declared in the APIs of the module. Each method of the set of methods is declared in at least one API of the module and is called by at least one module of the set of modules.
In an embodiment of the present invention, l^{p) denotes a set of all S-APIs of module p. For an S-API / of the set l^(p), M(i) denotes a set of methods declared in the S-API /. The set of other modules calling at least one method of the set M(i) is denoted as CallingModeO).




2. Metrics associated with inheritance-based coupling of the module
Inheritance is a property of object-oriented programming. Using inheritance, a class can be defined in such a way that it derives attributes and methods from the other classes of the object-oriented program. For example, a software product can be launched with customization functionality. The customization functionality enables the buyer of the software product to extend the functionality of the software product by creating new classes derived from the classes of the software product. If a new class defined by the buyer Is defined in module A and the new class is derived from a base class defined in module B, module A and module B become Inter-dependent. If the new class inherits Information declared in the APIs of module A, the base class can be changed without affecting the functionality of the new class in module B, and vice versa. However, If this is not true, making a change in the base class affects the functionality of the new class in module B, and vice versa. This Is known as fragile base class problem. Therefore, metrics have been defined to measure the Interdependence, induced by inheritance, between the modules of the object-oriented program.
In an embodiment of the present invention, there are two metrics associated with the inheritance-based coupling of the module. They are Base Class Fragile Index (BCFI) and Inheritance-Based Inter-Module Coupling Metric. The calculation of these metrics has been further explained below in detail.
a. Base Class Fragile Index (BCFI)
In an embodiment of the present invention, the metric associated with the Inheritance-based coupling of the module measures the degree to which the fragile base class problem is present in the object-oriented program. The metric is based on a set of concrete methods and the number of times each concrete method Is overridden outside a module defining the concrete method. Each concrete method of the set of concrete methods is called by at least one method of the one or more methods of the module and defined by the at least one class or an ancestor of the at least one class.
In an embodiment of the invention, for a class c of a module p, the set of concrete methods inherited from the ancestor classes of class c, and not overridden in the class c, Is denoted as Manc(c).



'


with the other modules of the object-oriented program. The metric is based on a set of other modules, a first set of classes and a second set of classes. Each module of the set of other modules defines at least one class, which is derived from a class of the one or more classes of the module. Each class of the first set of classes is derived from a class of the one or more classes of the module. Further, each class of the second set of classes is a class of the one or more classes and derived from a class defined in the other modules of the object-oriented program. In the ideal event, none of the classes defined in a module is derived from the classes defined outside the module.



In the object-oriented program, a class defined in module A can access another class defined in module B as an attribute or a parameter in method definitions. This results in a dependency between module A and module B. The metric associated with the association-based coupling measures the degree of this dependency.
In an embodiment of the present invention, the metric associated with the association-based coupling of the module is based on a set of other modules of the one or more modules, a first set of classes and a second set of classes. Each module of the set of other modules includes at least one class that uses at least one class of the module as an attribute or a parameter in method definitions. Each class of the first set of classes is defined in a module of the set of other modules and uses at least one class defined in the module as an attribute or a parameter in its method definitions. Further, each class of the second set of classes is defined in the module and uses at least one class defined in other modules as an attribute or a parameter in its method definitions.

I
I


4. Metrics Associated With the Size of the Module
During the development of a software product, good programming practice is to keep track of the size variation among classes in a module and among modules in the object-oriented program. A class that is disproportionately larger than the other classes of the module indicates that the class is not cohesive, i.e., the class does not have a single functionality. In this case the class can be replaced by classes small in size that individually offer a single functionality to the software product. Similarly, a module disproportionately larger than the other modules of the object-oriented program can be disintegrated into small modules.
In an embodiment of the present invention, there are three metrics associated with the size-based coupling of the module. The three metrics are index to measure size variability in number of classes of modules (MU(S}), index to measure class size variability by counting number of methods in classes (CUm (S)) and index to measure class size variability by counting number of lines of code in classes (CUi (S)). The calculation of these metrics has been further explained below in detail.
a. Index to measure size variability in number of classes of modules (MU)
In an embodiment of the present invention, the metric based on the size of the module represents the variation in the number of classes in the modules of the object-oriented program. The metric is based on the average size of the at least one module.

Further, the metric is based on the standard deviation of the average size. The size of a module is determined by the number of classes in the module.
In an embodiment of the present invention, the metric representing the variation in the number of classes in the modules is denoted as MU (S). The value of the metric lies in the range of 0 to 1. The value of 1 indicates that all the modules of the object oriented-program implement the same number of classes.

Where, |jp denotes the average size of the module p, and Op denotes the standard deviation of the average size.
b. Index to measure class size variabilitv by counting number of methods in classes
In an embodiment of the present invention, the metric associated with the size of the module measures the size variability among the one or more classes of the module. The metric is based on the average size of the one or more classes of the module. Further, the metric is based on the standard deviation of the average size. The average size of the classes is determined by the number of methods defined in the one or more classes.
In an embodiment of the present invention, the metric representing the size variability among the one or more classes of the module p is denoted as CUm(S). The value of the metric lies in the range of 0 to 1. The value of 1 indicates that all the classes of the module are of the same size in terms of the number of methods defined in the classes.


Where, ^m(W denotes the average size of the module p, and 0!n(p) denotes the standard deviation of the average size.
c. Index to measure class size variabilitv by counting number of lines of code in classes
In an embodiment of the present invention, the metric associated vi/ith the size of the module measures the size variability among the one or more classes of the module. The metric is based on the average size of the one or more classes of the module. Further, the metric is based on the standard deviation of the average size. The average size of the classes is determined by the number of lines of code in the one or more classes.
In an embodiment of the present invention, the metric representing the size variability among the one or more classes of the module p is denoted as CUi(S}. The value of the metric lies in the range of 0 to 1. The value of 1 indicates that all the classes of the module are of the same size in terms of the number of lines of code in the classes.

Where, ^i(p) denotes the average size of the module p, and Oi(p) denotes the standard deviation of the average size.
5. Metrics Associated wth the State Access-Based Coupling of the Module
The state of a class defined in a module of the object-oriented program is determined by the attributes declared in the class. The attributes that are not declared as private can be accessed by the other classes of the object-oriented program. When an attribute of a class defined in module A is accessed by another class defined in module B, module B directly accesses the state of module A. This results in inter-module access of state.

The metric associated with the state access-based coupling of the module measures the extent to which the state of a class in a module is accessed by classes of other modules. The metric is based on a set of other modules, a first set of attributes, a second set of attributes and a set of classes. Each module of the set of other modules accesses at least one attribute of the one or more attributes defined in a class of the one or more classes of the module. Each attribute of the first set of attributes is defined in a class of the one or more classes and accessed by the classes defined in the other modules of the object-oriented program, Each attribute of the second set of attributes is defined in a class of the module and accessed by the other classes of the module. Further, each class of the set of classes is defined in the module and accesses at least one class defined in the module. In an ideal situation, the state of any class defined in the module is not accessed by a class defined outside the module.


Where, p' is a module of the object-oriented program, C(p') denotes the set of classes defined in module p', and used(a,d) is a predicate, which is true when class a uses class d.


the present invention uses a frequent-item set mining algorithm called Apriorr. This algorithm can be employed to find frequently occurring sets of Items in a large database of items. In an embodiment of the present invention, each class in the module is considered an item.
The metric associated with the use of the module measures the extent to which classes being used together are packaged together in a module. The metric is based on a set of classes and a set of modules. Each class of the set of classes is used together In the object-oriented program. Further, each module of the set of modules defines at least one class of the set of classes. In the ideal event, all the classes used together are defined in a module.



The calculated value of the metric is compared to the corresponding pre-defined threshold. For example, the value of the metric Mll(p) is compared to the range 0 to 1. When the value of Mll(p) is equal to 0.8, It can be inferred that module p is near to the

ideal state of modularity. On the other hand, when the value of the metric Mll(p) is 0.1, it can be inferred that module p has poor inter-module interaction. Similarly, all the other metrics calculated at step 102 can be analyzed to assess the modularity of the object-oriented program. In an embodiment of the present invention, the results obtained from the analysis of the metrics are presented to the users in the form of graphical reports such as charts, tables, and the like. It may be apparent to any person skilled in the art that there may be various other forms of graphical reports. An exemplary chart 202 depicting the results of the analysis is shown in FIG. 2. In chart 202, the x-axis depicts the various metrics described above, and the y-axis depicts the calculated values of these metrics for software systems such as Compiere, P-CRM, Pet-Store, and FinApp. The value of SCF/for FineApp is 1, which indicates that the problem of base class fragility does not exist in FineApp.
In an embodiment of the present invention, all the metrics described above are analyzed. In another embodiment of the present invention, metrics selected by a user are analyzed.
FIG. 3 is a block diagram illustrating a system 302 configured to assess the modularity of an object-oriented program. The object-oriented program is associated with a plurality of properties. Various examples of the properties include, but are not limited to, inheritance, polymorphism, abstraction, containment, and encapsulation.
As explained earlier, the object-oriented program includes a plurality of modules. At least one module of the plurality of modules includes one or more classes and one or more APIs. Further, at least one class of the one or more classes includes one or more methods and one or more attributes.
System 302 includes a processing module 304 and an analysis module 306.
Processing module 304 calculates at least one metric for each of the at least one module. Each of the at least one metric is based on a property of the plurality of properties. In an embodiment of the present invention, processing module 304 calculates the metrics associated with one of API-based coupling of the module,

inheritance-based coupling of the module, association-based coupling of the module, state access-based coupling of the module, size of the module and use of the module. The calculation of the at least one metric has been explained in detail in conjunction with FIG. 1 at step 102.
Analysis module 306 analyzes the at least one calculated metric, based on a pre¬defined threshold value. The analysis of the at least one metric has been explained in conjunction with FIG. 1 at step 104. Further, analysis module 306 generates graphical reports to present the results obtained from the analysis of the metrics to the users. An exemplary chart generated by analysis module 306 has been explained in conjunction with FIG. 2.
In an embodiment of the present invention, analysis module 306 analyzes all the metrics described above. In another embodiment of the present invention, analysis module 306 analyzes metrics selected by a user.
In various embodiments of the invention, processing module 304 and analysis module 306 can be implemented in the form of hardware, software, firmware and/or combinations thereof.
The process, system and computer program product described above have a number of advantages. The process enables calculation of metrics to quantitatively measure the modularity of the object-oriented program. Further, these metrics are calculated at the level of niodules and based on various properties of the object-oriented program, such as interdependence induced among the modules due to properties such as inheritance, polymorphism, abstraction and containment. Since the metrics are calculated at the level of modules, the present invention overcomes the disadvantages of calculating the metrics at the level of classes. Furthermore, the system displays the calculated values of the metrics in the form of graphical reports to the users. These graphical reports enable the users to monitor the modularity of the object-oriented program and identify the reasons for degradation in modularity.
The system for assessing the modularity of an object oriented program, as described in the present invention or any of its components, may be embodied in the

form of a computer system. Typical examples of a computer system include a general-purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices that are capable of implementing the steps that constitute the method of the present invention.
The computer system comprises a computer, an input device, a display unit and the Internet. The computer further comprises a microprocessor, which is connected to a communication bus. The computer also includes a memory, w/hich may include Random Access Memory (RAM) and Read Only Memory (ROM). The computer system also comprises a storage device, which can be a hard disk drive or a removable storage drive such as a floppy disk drive, an optical disk drive, etc. The storage device can also be other similar means of loading computer programs or other instructions to the computer system. The computer system also includes a communication unit, which enables the computer to connect to other databases and the Internet through an Input/ Output (I/O) interface. The communication unit also enables the transfer as well as reception of data from other databases. The communication unit may include a modem, an Ethernet card, or any similar device which enable the computer system to connect to databases and networks such as Local Area Network (LAN), Metropolitan Area Network (MAN), Wide Area Network (WAN) and the Internet. The computer system facilitates inputs from a user through an input device, accessible to the system through an I/O interface.
The computer system executes a set of instructions that is stored in one or more storage elements, to process the input data. The storage elements may also hold data or other information as desired. The storage element may be in the form of an information source or a physical memory element present in the processing machine.
The present invention may also be embodied in a computer program product to assess the modularity of the object-oriented program. The computer program product includes a computer-usable medium having a set of program instructions comprising a program code to assess the modularity of the object-oriented program. The set of instructions may include various commands that instruct the processing machine to perform specific tasks such as the steps that constitute the method of the present invention. The set of instructions may be in the form of a software program. Further, the

software may be in the form of a collection of separate programs, a program module with a large program or a portion of a program module, as described in the present invention. The software nfiay also include modular programming in the form of object-oriented programming. The processing of input data by the processing machine may be in response to user commands, results of previous processing or a request made by another processing machine.
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not limit to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention, as described in the claims.

We claim:
I. A process for assessing modularity of an object oriented program, a plurality of properties being associated with the object oriented program, the object oriented program comprising a plurality of modules, at least one module of the plurality of nodules comprising one or more classes and one or more application programming interfaces (APIs), at least one class of the one or more classes comprising one or more attributes and one or more methods, the process comprising:
a. calculating at least one metric for each of the at least one module, wherein each
of the at least one metric is associated with one property of the plurality of
properties associated with the object oriented program; and
b. analyzing the at least one calculated metric based on a pre-defined threshold
value, wherein the analysis facilitates the assessment of the modularity of the
object oriented program.
The process according to claim 1, wherein the one property of the plurality of properties is one of API based coupling of the at least one module, inheritance based coupling of the at least one module, association based coupling of the at least one nodule, state access based coupling of the at least one module, size of the at least one nodule and usage of the at least one module.
The process according to claim 1, further comprising generating one or more graphical reports based on the analysis of the at least one calculated metric.
I. The process according to claim 2, wherein the at least one metric associated with the API based coupling of the at least one module is based on a first set of external calls and a second set of external calls, each of the first set of external calls being made to a subset of the one or more methods, the subset of the one or more methods being leclared in at least one API of the one or more APIs of the at least one module, each of he second set of external calls being made to the one or more methods.

5. The process according to claim 2, wherein the at least one metric associated with the
API based coupling of the at least one module is based on a set of public methods of the
one or more methods, a set of non-API methods of the set of public methods and a set
of API methods of the set of public methods, wherein each method of the set of non-API
methods is not called by other modules of the object oriented program, each method of the set of API methods being declared in at least one API of the one or more APIs of the at least one module.
6. The process according to claim 2, wherein the at least one metric associated with the
API based coupling of the at least one module is based on a set of abstract methods
and a set of concrete methods, each abstract method of the set of abstract methods being defined in a class of the object oriented program and called by at least one method of the one or more methods, each concrete method of the set of concrete methods being defined in a class of an inheritance hierarchy and called by at least one method of the one or more methods.
7. The process according to claim 2, wherein the at least one metric associated with the API based coupling of the at least one module is based on a set of modules of the plurality of modules and a set of methods, wherein each module of the set of modules calls at least one method of one API of the one or more APIs, each method of the set of methods being called by at least one module of the set of modules, wherein each method of the set of methods is declared in the one API.
8. The process according to claim 2, wherein the at least one metric associated with the inheritance based coupling of the at least one module is based on a set of concrete methods and number of times each concrete method of the set of concrete methods is overridden, wherein each concrete method of the set of concrete methods is overridden outside a module of the plurality of modules defining the concrete method, each concrete method of the set of concrete methods being called by at least one method of the one or more methods, each concrete method of the set of concrete methods being defined by at least one of the at least one class and at least one of ancestor classes of the at least one class.

9. The process according to claim 2, wherein the at least one metric associated with the
inheritance based coupling of the at least one module is based on a set of other
modules of the plurality of modules, a first set of classes and a second set of classes,
each module of the set of other modules having at least one class derived from at least
one class of the one or more classes of the at least one module, each class of the first
set of classes being derived from at least one class of the one or more classes of the at
least one module, each class of the second set of classes is a class of the one or more
classes and derived from at least one class of at least one module of the other modules.
10. The process according to claim 2, wherein the at least one metric associated with the association based coupling of the at least one module is based on a set of other modules of the plurality of modules, a first set of classes and a second set of classes, each module of the set of other modules having at least one class using at least one class of the one or more classes as a parameter in method definitions, each class of the first set of classes using at least one class of the one or more classes as a parameter in method definitions , each class of the second set of classes using at least one class of at least one module of other modules as a parameter in method definitions, wherein each class of the second set of classes is a class of the one or more classes.
11. The process according to claim 2, wherein the at least one metric associated with the size of the at least one module is based on an average size of the at least one module and standard deviation of the average size of the at least one module, the average size of the at least one module being associated with the number of classes in the at least one module.
12. The process according to claim 2, wherein the at least one metric associated with the size of the at least one module is based on an average size of the one or more classes of the at least one module and standard deviation of the average size of the one or more classes, the average size of the one or more classes being associated with the number of methods in each of the one or more classes.
13. The process according to claim 2, wherein the at least one metnc associated with the size of the at least one module is based on an average size of the one or more

classes of the at least one module and standard deviation of the average size of the one or more classes, the average size of the one or more classes being associated with the number of lines of code in each of the one or more classes.
14. The process according to claim 2, wherein the at least one metric associated with the state access based coupling of the at least one module is based on a first set of attributes, a set of other modules, a second set of attributes and a set of classes, each attribute of the first set of attributes being an attribute of the one or more attributes and being accessed by at least one class of at least one module of other modules, each module of the set of other modules accessing at least one attribute of the one or more attributes, each attribute of the second set of attributes being defined in at least one class of the one or more classes and being accessed by other classes of the one or more classes, each class of the set of classes being a class of the one or more classes and accessing at least one attribute of other classes of the one or more classes.
15. The process according to claim 2, wherein the at least one metric associated with the usage of the at least module is further based a set of classes and a set of modules of the plurality of modules, each class of the set of classes being used together in the object oriented program, wherein each module of the set module defines at least one class of the set of classes.
16. A system configured to assess modularity of an object oriented program, a plurality of properties being associated with the object oriented program, the object oriented program comprising a plurality of modules, at least one module of the plurality of modules comprising one or more classes and one or more application programming interfaces (APIs), at least one class of the one or more classes comprising one or more attributes and one or more methods, the system comprising:
a. a processing module is configured for calculating at least one metric for each of the at least one module, wherein the each of the at least one metric is associated with one property of the plurality of properties associated with the object oriented program; and

b. an analysis module configured for analyzing the at least one calculated metric based on a pre-defined threshold value, wherein the analysis facilitates the assessment of the modularity of the object oriented program.
17. The system according to claim 16, wherein the one property of the plurality of properties is one of API based coupling of the at least one module, inheritance based coupling of the at least one module, association based coupling of the at least one module, state access based coupling of the at least one module, size of the at least one module and usage of the at least one module.
18. The system according to claim 16, wherein the analysis module is further configured for generating one or more graphical reports based on the analysis of the at least one calculated metric.
19. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the API based coupling of the at least one module, the at least one metric being based on a first set of external calls and a second set of external calls, each of the first set of external calls being made to a subset of the one or more methods, of the subset of the one or more methods being declared in at least one API of the one or more APIs of the at least one module, each of the second set of external calls being made to the one or more methods.
20. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the API based coupling of the at least one module, the at least one metric being based on a set of public methods of the one or more methods, a set of non-API methods of the set of public methods and a set of API methods of the set of public methods, wherein each method of the set of non-API methods is not called by other modules of the object oriented program, each method of the set of API methods being declared in at least one API of the one or more APIs of the at least one module.
21. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the API based coupling

of the at least one module, the at least one metric being based on a set of abstract methods and a set of concrete methods, each abstract method of the set of abstract methods being defined in a class of the object oriented program and called by at least one method of the one or more methods, each concrete method of the set of concrete methods is defined in a class of an inheritance hierarchy and called by at least one method of the one or more methods.
22. The system according to claim 17, wherein the processing module is further
configured for calculating the at least one metric associated with the API based coupling
of the at least one module, wherein the at least one metric associated with the API
based coupling of the at least one module is based on a set of modules of the plurality of
modules and a set of methods, wherein each module of the set of modules calls at least
one method of one API of the one or more APIs, each method of the set of methods
being called by at least one module of the set of modules, wherein each method of the
set of methods is declared in the one API.
23. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the inheritance based coupling of the at least one module, the at least one metric being based on a set of concrete methods and number of times each concrete method of the set of concrete methods is overridden, wherein each concrete method of the set of concrete methods is overridden outside a module defining the concrete method, each concrete method of the set of concrete methods being called by at least one method of the one or more methods, each concrete method of the set of concrete methods being defined by at least one of the at least one class and at least one of ancestor classes of the at least one class.
24. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the inheritance based coupling of the at least one module, the at least one metric being based on a set of other modules of the plurality of modules, a first set of classes and a second set of classes, each module of the set of other modules having at least one class derived from at least one class of the one or more classes of the at least one module, each class of the first

set of classes being derived from at least one class of the one or more classes of the at least one module, each class of the second set of classes is a class of the one or more classes and derived from at least one class of at least one module of the other modules.
25. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the association based coupling of the at least one module, the at least one metric being based on a set of other modules of the plurality of modules, a first set of classes and a second set of classes, each module of the set of other modules having at least one class using at least one class of the one or more classes as a parameter in method definitions, each class of the first set of classes using at least one class of the one or more classes as a parameter in method definitions , each class of the second set of classes using at least one class of at least one module of other modules as a parameter in method definitions, wherein each class of the second set of classes is a class of the one or more classes.
26. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the size of the at least one module, the at least one metric being based on an average size of the at least one module and standard deviation of the average size of the at least one module, the average size of the at least one module being associated with the number of classes in the at least one module.
27. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the size of the at least one module, the at least one metric being based on an average size of the one or more classes of the at least one module and standard deviation of the average size of the one or more classes, the average size of the one or more classes being associated with the number of methods in each of the one or more classes.
28. The system according to claim 17. wherein the processing module is further configured for calculating the at least one metric associated with the size of the at least one module, the at least one metric being based on an average size of the one or more classes of the at least one module and standard deviation of the average size of the one

or more classes, the average size of the one or more classes being associated with the number of lines of code in each of the one or more classes.
29. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the state access based coupling of the at least one module, the at least one metric being based on a first set of attributes, a set of other modules, a second set of attributes and a set of classes, each attribute of the first set of attributes being an attribute of the one or more attributes and being accessed by at least one class of at least one module of other modules, each module of the set of other modules accessing at least one attribute of the one or more attributes, each attribute of the second set of attributes being defined in at least one class of the one or more classes and being accessed by other classes of the one or more classes, each class of the set of classes being a class of the one or more classes and accessing at least one attribute of other classes of the one or more classes.
30. The system according to claim 17, wherein the processing module is further configured for calculating the at least one metric associated with the usage of the at least one module, wherein the at least one metric associated with the usage of the at least module is further based a set of classes and a set of modules of the plurality of modules, each class of the set of classes being used together in the object oriented program, wherein each module of the set module defines at least one class of the set of classes.
31. A computer program product for use with a computer, the computer program product comprising a computer usable medium having a computer readable program code embodied therein for assessing modularity of an object oriented program, a plurality of properties being associated with the object oriented program, the object oriented program comprising a plurality of modules, at least one module of the plurality of modules comprising one or more classes and one or more application programming interfaces (APIs), at least one class of the one or more classes comprising one or more attributes and one or more methods, the computer readable program code performing:

a. calculating at least one metric for each of the at least one module, wherein the
each of the at least one metric is associated with one property of the plurality of
properties associated with the object oriented program; and
b. analyzing the at least one calculated metric based on a pre-defined threshold
value, wherein the analysis facilitates the assessment of the modularity of the
object oriented program.
32. The computer program product according to claim 31, wherein the one property of the plurality of properties is one of API based coupling of the at least one module, inheritance based coupling of the at least one module, association based coupling of the at least one module, state access based coupling of the at least one module, size of the at least one module and usage of the at least one module.
33. The computer program product according to claim 31, wherein the computer readable program code further performs generating one or more graphical reports based on the analysis of the at least one calculated metric.
34. The computer program product according to claim 32, wherein the at least one metric associated with the API based coupling of the at least one module is based on a first set of external calls and a second set of external calls, each of the first set of external calls being made to a subset of the one or more methods, the subset of the one or more methods being declared in at least one API of the one or more APIs of the at least one module, each of the second set of external calls being made to the one or more methods.
35. The computer program product according to claim 32, wherein the at least one metric associated with the API based coupling of the at least one module is based on a set of public methods of the one or more methods, a set of non-API methods of the set of public methods and a set of API methods of the set of public methods, wherein each method of the set of non-API methods is not called by other modules of the object oriented program, each method of the set of API methods being declared in at least one API of the one or more APIs of the at least one module.

36. The computer program product according to claim 32, wherein the at least one metric associated with the API based coupling of the at least one module is based on a set of abstract methods and a set of concrete methods, each abstract method of the set of abstract methods being defined in a class of the object oriented program and called by at least one method of the one or more methods, each concrete method of the set of concrete methods being defined in a class of an inheritance hierarchy and called by at least one method of the one or more methods.
37. The computer program product according to claim 32, wherein the at least one metric associated with the API based coupling of the at least one module is based on a set of modules of the plurality of modules and a set of methods, wherein each module of the set of modules calls at least one method of one API of the one or more APIs, each method of the set of methods being called by at least one module of the set of modules, wherein each method of the set of methods is declared in the one API.
38. The computer program product according to claim 32, wherein the at least one metric associated with the inheritance based coupling of the at least one module is based on a set of concrete methods and number of times each concrete method of the set of concrete methods is overridden, wherein each concrete method of the set of concrete methods is overridden outside a module of the plurality of modules defining the concrete method, each concrete method of the set of concrete methods being called by at least one method of the one or more methods, each concrete method of the set of concrete methods being defined by at least one of the at least one class and at least one of ancestor classes of the at least one class.
39. The computer program product according to claim 32, wherein the at least one metric associated with the inheritance based coupling of the at least one module is based on a set of other modules of the plurality of modules, a first set of classes and a second set of classes, each module of the set of other modules having at least one class derived from at least one class of the one or more classes of the at least one module, each class of the first set of classes being derived from at least one class of the one or more classes of the at least one module, each class of the second set of classes is a

class of the one or more classes and derived from at least one class of at least one module of the other modules.
40. The computer program product according to claim 32, wherein the at least one metric associated with the association based coupling of the at least one module is based on a set of other modules of the plurality of modules, a first set of classes and a second set of classes, each module of the set of other modules having at least one class using at least one class of the one or more classes as a parameter in method definitions, each class of the first set of classes using at least one class of the one or more classes as a parameter in method definitions , each class of the second set of classes using at least one class of at least one module of other modules as a parameter in method definitions, wherein each class of the second set of classes is a class of the one or more classes.
41. The computer program product according to claim 32, wherein the at least one metric associated with the size of the at least one module is based on an average size of the at least one module and standard deviation of the average size of the at least one module, the average size of the at least one module being associated with the number of classes in the at least one module.
42. The computer program product according to claim 32, wherein the at least one metric associated with the size of the at least one module is based on an average size of the one or more classes of the at least one module and standard deviation of the average size of the one or more classes, the average size of the one or more classes being associated with the number of methods in each of the one or more classes.
43. The computer program product according to claim 32, wherein the at least one metric associated with the size of the at least one module is based on an average size of the one or more classes of the at least one module and standard deviation of the average size of the one or more classes, the average size of the one or more classes being associated with the number of lines of code in each of the one or more classes.

44. The computer program product according to claim 32, wherein the at least one metric associated with the state access based coupling of the at least one module is based on a first set of attributes, a set of other modules, a second set of attributes and a set of classes, each attribute of the first set of attributes being an attribute of the one or more attributes and being accessed by at least one class of at least one module of other modules, each module of the set of other modules accessing at least one attribute of the one or more attributes, each attribute of the second set of attributes being defined in at least one class of the one or more classes and being accessed by other classes of the one or more classes, each class of the set of classes being a class of the one or more classes and accessing at least one attribute of other classes of the one or more classes.
45. The computer program product according to claim 32, wherein the at least one metric associated with the usage of the at least module is further based a set of classes and a set of modules of the plurality of modules, each class of the set of classes being used together in the object oriented program, wherein each module of the set module defines at least one class of the set of classes.