Towards A Dynamic Object-Oriented Design Metric Plug-in Framework

: Problem Statement: The evolution of software is made difficult by the need to integrate new features with all previously implemented features in software applications. Approach: present study introduced a general-purpose, platform-independent object-oriented design metric plug-in framework called jmetric intended to help building scalable, extendable object-oriented design metric plug-ins. jmetric seeks to address problem by providing the plug-in developer a structured way to separately develop and incrementally integrate independent object-oriented design metrics as plug-ins to a domain specific object-oriented design metrics framework. jmetric was engineered to provide functional building blocks to accelerate the adding, removing and updating of object-oriented design metric plug-ins in tools such as Eclipse, JDeveloper, NetBeans, JBuilder and other Java-based tools. Dependency injection is heavily used in jmetric to accelerate the adding, removing and updating of object-oriented metrics plug-ins. We studied several commonly used integrated development environments and software metrics tools to identify the extendibility of the tools to provide additional object-oriented design metric functionalities as plug-ins. Results: We demonstrate a tool called jmetric tool that had developed as a reference implementation to validate the plug-in capabilities of jmetric. Conclusion: Extending other tools such as Eclipse, JDeveloper and NetBeans to include metric functionalities is possible by wiring plug-ins through dependency injection mechanism in jmetric.


INTRODUCTION
Measurement is recognized as a key element of any engineering process. We use measures to assess the quality of an engineered product. Examples are analysis models, design models and other software artifacts. The IEEE-computer society, with the support of a consortium of industrial sponsors, has published a guide to the Software Engineering Body of Knowledge and, throughout this guide, measurement is pervasive as a fundamental engineering tool [1] . A few researchers such as Harrison, Counsell and Nithi, Chidamber and Kemerer and Lorenz and Kidd have proposed a number of design metrics for object-oriented systems. Examples are weighted methods per class, depth of inheritance tree, number of children, coupling between object classes, response for a class, lack of cohesion in methods, class size, number of operations overridden by a subclass, number of operations added by a subclass and method inheritance factor [3,4,7,11,14,16] . Most of the software metric tools such as Resource Standard Metrics, Essential Metrics, Krakatau Metrics, CodeReports, DeepCover and Together ControlCenter are based on a closed architecture relying heavily on proprietary constraints such as vendor specific APIs. As such, we introduce jmetric, an open architecture framework intended to help building scalable, extendable objectoriented design metric plug-ins. jmetric allows the adding, removing and updating (i.e., upgrading and swapping) of plug-ins easily through subclassing the required abstract classes. Hence, object-oriented metrics such as depth of inheritance tree, number of public attributes and public method density are implemented as add-ons to tools such as jmetric tool and Eclipse.

MATERIALS AND METHODS
We have studied several commonly used software metrics tools and categorized the tools into standalone tools and IDEs. Table 1 and 2 show the tools that we have studied.  Motivation: Based on our classification schemes shown in Table 3 and 4, we believed having a good object-oriented design metric plug-in framework in place allows metric plug-in developers to spend more time concentrating in implementing specific objectoriented design metrics rather than dealing with lowlevel details. This leads to a distinctive breakdown of jmetric at the design stage into frozen spots and hot spots.
Frozen spots: Frozen spots represent the overall architecture of jmetric (i.e., its basic components and the relationships between them). These remain unchanged (i.e., frozen) in any instantiation of jmetric.
Hot spots: Hot spots represent those parts where specific object-oriented design metrics are implemented independently as plug-ins. In our study, we intend to design a lowly coupled object-oriented design metric plug-in framework. As such, the design of jmetric is based on the Hollywood Principle: "Don't call us, we'll call you." [13] . A good object-oriented design metric plug-in framework also needs to include techniques to decouple high-level modules from low-level modules. The dependency injection principle is employed to fulfill such objective. jmetric used the interface injection heavily in which alternative implementations of a specified plug-in can be easily integrated at runtime into jmetric via a configuration file. There are three ways in which an object can reference an external module, according to the pattern used to provide the dependency: • Type 1 or interface injection, in which the exported module provides an interface that its users must implement in order to get the dependencies at runtime • Type 2 or setter injection, in which the dependent module exports a setter method that the framework uses to inject the dependency • Type 3 or constructor injection, in which the dependencies are provided through the class constructor [10,15]   Dependency injection is very effective at assembling loosely coupled plug-ins and at configuring these plug-ins. Specifically, jmetric uses dependency injection to: • Inject the same dependency into multiple plug-ins • Inject different implementations of the same dependency • Inject the same implementation in different configurations Jmetric high-level architecture: We have developed a framework and a tool (i.e., a reference implementation of jmetric) known as jmetric and jmetric tool respectively to predict metrics such as number of operations overridden by a subclass tree, number of operations added by a subclass, percent public and protected, number of children and depth of the inheritance tree. Figure 1 shows the high-level architecture of jmetric.  Fig. 1: jmetric high-level architecture jmetric plug-in framework is a general-purpose framework intended to help building scalable, extendable Jmetric components. The plug-in framework provides a runtime engine that dynamically registers, unregisters, loads and unloads plug-ins. The plug-in framework is engineered in such a way that additional application-specific plug-ins can be created in order to meet application-specific requirements. Generally, the framework consists of abstract and concrete classes that describe specific object-oriented design metrics via plug-ins. Any instantiation of jmetric consists of composing and subclassing the existing abstract classes.
There are typically three types of plug-ins, namely jmetric algorithm plug-ins, jmetric chart plug-ins and jmetric data source plug-ins. A jmetric plug-in is a structured component that describes itself to the jmetric plug-in framework through standard Java property files.

Jmetric algorithm plug-ins:
A jmetric algorithm plugin is a structured component that describes a metric. Examples of jmetric algorithms are depth of inheritance tree and number of operations overridden by a subclass tree.

Jmetric chart plug-ins:
A jmetric chart plug-in is a structured component that describes the indexes of a metric graphically. Examples of jmetric chart plug-ins are scaled chart, bar chart and line chart. Jmetric data source plug-ins: A jmetric data source plug-in is a structured component that describes a data source, for example, a directory, a JAR file (i.e., Java Archive), a WAR file (i.e., Web Application Archive) and a ZIP file (i.e., Compressed File Archive).
Jmetric tool, Eclipse, JDeveloper and other Javabased tools are considered as application systems. The application systems rely heavily on the plug-in framework to interact with specific types of plug-ins: jmetric algorithm plug-ins and jmetric chart plug-ins.
Jmetric layered architecture: Figure 2 shows the jmetric layered architecture. Each jmetric plug-in may rely on services provided by other jmetric plug-ins and each may in turn provide services on which other jmetric plug-ins may rely. The SI (i.e., Specialization index) plug-in relies on NOO (i.e., Number of operations overridden by a subclass). The specialization index provides an indication of the degree of specialization for each of the subclasses in an objectoriented system [16] . The metric relies on NOO metric as one of the numerators of SI metric. JAR plug-in relies on ZIP plug-in as JAR files are based on ZIP file format specification.
Jmetric runs on any Java Virtual Machine (JVM) that adheres to the JVM specification published by Sun. Different reference implementations of JVMs supported by jmetric are Sun JVM, Oracle JVM and IBM JVM.
The JVM parameters such as -Xmsn (i.e., to specify the initial size, in bytes, of the memory allocation pool) and -Xmxn (i.e., to specify the maximum size, in bytes, of the memory allocation pool) can be configured accordingly to tune the performance of jmetric on different operating systems.
Jmetric repository consists of jmetric plug-in loader and jmetric class library. The jmetric plug-in loader implements the runtime engine that dynamically discovers and activates jmetric plug-ins. The jmetric class library is a standard library of classes and interfaces that brings together a large number of objectoriented design metrics functions. The library is designed as the foundation on which jmetric plug-ins such as jmetric algorithm plug-ins and jmetric data source plug-ins are built.
Jmetric maintains a registry of available plug-ins and the functions they provide via variation points (also known as extension points) and variants (also known as extensions). To simplify distribution of plug-ins, a jmetric plug-in may be packaged as single JAR file that is unpacked transparently in runtime.
Jmetric Plug-in High Level Architecture: Figure 3 shows the jmetric plug-in high-level architecture. A jmetric plug-in (also known as add-in, add-on or snapin) is a structured component that describes itself to jmetric through a standard configuration file (i.e., a standard Java properties file) [2,5,6,12] . jmetric maintains a registry of available plug-ins and the functions they provide through extension points (also known as variation points) and extensions (variants). The jmetric plug-ins are designed based on nine distinctive design characteristics: complexity (i.e., a low effort is required in understanding an operational jmetric plug-in), flexibility (i.e., a low effort required in modifying an operational jmetric plug-in), maintainability (i.e., a low effort is required in maintaining an operational jmetric plug-in), reusability (i.e., a low effort is required in reusing an operational jmetric plug-in), testability (i.e., a low effort is required in testing an operational jmetric plug-in), operability (i.e., a low effort is required in operating an operational jmetric plug-in), traceability (i.e., a low effort is required in tracing an operational jmetric plug-in), interoperability (i.e., a low effort is required in interoperating an operational jmetric plug-in among different tools).
A jmetric plug-in may itself be augmented by different kinds of extensions. jmetric plug-ins provide different types of slots (i.e., extension points) that extensions (i.e., other jmetric plug-ins) can plug into. A jmetric plug-in (e.g., NOO plug-in) allows three types of slots (i.e., algorithms, charts and data sources) upon which any number of a jmetric extender plug-in (e.g., SI plug-in) can be plugged. Variability mechanisms are used in conjunction with each other to help building a small, coherent number of plug-ins [9] . Through variability mechanisms, the components of jmetric can be combined in a variety of ways to produce the desired plug-ins effectively and efficiently. jmetric implemented the inheritance (i.e., via virtual operation extension point type), configuration (i.e., via configuration item slot extension point type) and parameters (i.e., via parameter extension point type) variability mechanisms.

RESULTS
We have developed a tool called jmetric tool as a reference implementation to illustrate the capabilities of the jmetric. A reference implementation is, in general, an implementation of a specification to be used as a definitive interpretation for that specification. During the development of the conformance test suite, at least one relatively trusted implementation of each interface is necessary to discover errors or ambiguities in the specification and validate the correct functioning of the test suite [8] . The jmetric reference implementation, jmetric tool (also known as jmetric sample implementation or jmetric model implementation) is a software example of jmetric plug-in specification intended to be used to help object-oriented design metric plug-in developers to implement their own version of plug-in specification. Figure 4 shows the jmetric tool that we have developed to validate the plug-in capabilities of jmetric, namely jmetric algorithm plug-ins, jmetric chart plugins and jmetric data source plug-ins. jmetric tool can be used to predict a number of metrics proposed by other researchers such as depth of inheritance tree, number of overridden methods, number of methods added, private attributes density and protected attributes attributes density. The tool categorizes object-oriented design metrics into four categories: Class-based metrics, attribute-based metrics, method-based metrics and candidate metrics. These are referred to as jmetric algorithms plug-in as shown in Fig. 1. The jmetric data source plug-ins such as JAR plug-in and ZIP plug-in are located under the File menu. Lastly, the jmetric chart plug-ins are located under the Graph tab of each metric.

DISCUSSION
Standalone tools: Most of the software metrics tools such as Krakatau Professional and Essential Metrics lack of a general-purpose, platform-independent plugin-based metric framework. Standalone tools such as JStyle, Krakatau Professional, Essential Metrics and McCabe IQ Developers Edition rely heavily on proprietary APIs. Extending the functionalities of these tools is not likely to be possible without the need to access vendor-specific native APIs. jmetric provides a Java-language alternative to these vendor-specific APIs through plug-ins. The plug-ins allow third-party tools (i.e., standalone software metrics tools, IDEs and other types of tools) to interface with jmetric.
IDEs: IDEs such as Eclipse IDE for Java EE Developers, Eclipse Classic, Eclipse IDE for Java Developers and NetBeans lack of software metrics functionalities. A few IDEs such as Visual Studio Team System (Development Edition and Team Suite) provides software metrics functionalities (referred to as code metrics) commercially off-the-shelf. Examples of code metrics provided by the IDE are Class Coupling, Depth of Inheritance and Cyclomatic Complexity. Extending the IDE to include other metrics is difficult as the IDE lacks of a domain specific framework that consists of specialized framework components on design metrics. jmetric accomplishes the goal to bridge between the IDEs and jmetric via jmetric plug-ins as most IDEs provide a way to extend the functionalities of the IDEs through plug-ins..

CONCLUSION
The primary objective of the research is to design and develop a lightweight object-oriented design metric framework that helps to assemble metrics into tools such as Eclipse and NetBeans via plug-ins. Underlying the framework is a common pattern to perform the wiring of plug-ins via dependency injection. Dependency injection is heavily used to accelerate the adding, removing and updating of object-oriented metrics plug-ins in tools such as Eclipse and JDeveloper. jmetric plug-ins are activated (i.e., loaded) lazily upon instantiating the framework but not deactivated (i.e., unloaded) when they are no longer required. This potentially causes the memory footprint to grow when more functionality are injected into the framework. In future, we intend to address this issue via a scheduling algorithm. Other future work includes extending the framework to other object-oriented programming languages such as Visual C# .NET and Visual Basic .NET through a service-oriented architecture. We also intend to investigate the possibilities to build an object-oriented metric domain specific language through Eclipse Modeling Framework and Domain Specific Language Tools for Visual Studio. Through the domain specific language, we plan to build an exemplary visual tool to provide a code generation facility via modeling based on a structured data model such as XML.