REVIEW OF METRICS EXTRACTION TOOL USING UML

In the present consequence, whole world depends on software. It is a cost effective way is essential because all countries depend on complex computer based systems. So it is a big challenge of the developers and researchers to adopt latest technologies which convert a highly complex system design into a simple design. Intended for this purpose, developers inspire the design and construction of computer-based systems by using reusable software which is called as component. A component can be deployed, as they possess the qualities such as reusability, stability, proper communication, modularity, testability, and complexity. The reusable components on integration interoperate with each other resulting in an operational application which is developed with minimum effort and low maintenance cost. We used Component Based Software Development (CBSD) process, which is based on the basic concepts of Object Orientated Techniques where Unified Modelling Language (UML) shows an important role. Different quality factors of a component are measured with the help of metrics, and there are number of metrics proposed for components. In this paper we proposed a methodology of static metrics for integration of software components, complexity metrics for UML Component-based System Specification (CBSS) and interface complexity metrics in a component assembly. These metrics are derived using UML artifacts. We derived these metrics by developing a tool named “CAME” (Component Assembly Metrics Extractor) in NetBeans which parses through the XMI file (XML Meta Data Interchange) generated by UML tool and produces different component metrics through graphic user interface. These metrics will help the software developer in making the system more stable, better and efficient


I. INTRODUCTION
Now these days the software systems are very difficult, bulky and unmanageable. This causes lesser productivity and higher risk management. Software metrics amount different features of software complexity and therefore play an important role in analyzing and improving the quality of software [Diwaker C., et.al., 2014]. The software metrics is used by all people involved in the development processes including customers and managers on one hand, and project leaders, designers and programmers on the other side. As an example, a software manager may be interested in lines of code, while a project manager may be interested in estimating the number of hours required to develop the same number of lines to calculate the productivity of programmers [Abreu F.B., W. Melo., 1996]. Software metric is a mapping from a software development domain to a numerical domain. Here software development domain means an analysis model or the source code of an application and numerical model means the real numbers. A metric must be strongly correlated with a quantitative or qualitative feature of the system. The aims of software metrics are essentially two:  to give hints on the quality of the system and  to estimate its development and maintenance costs.
The main purpose of reviewing this paper is to know about, how to design and implement metrics tool? In this paper, one metric tool has designed and implemented named CAME (Component Assembly Metrics Extraction). This tool is used to calculate metrics from UML design documents. It is capable of generating software metrics proposed by researchers for Component Based Software Systems. This paper, demonstrate the CAME tool for a University Case Registration System (UCRS) and its representation in UML and metrics extraction procedure [Pandey; Shareef , 2013].

II. METRICS FOR THE INTEGRATION OF SOFTWARE COMPONENTS
To measure complexity and criticality of large software systems designed and integrated using the principles of CBSE (Component Based Software Engineering), V. L. Narasimhan and B. Hendradjaya, 2004 has proposed two sets of metrics i.e. static and dynamic metrics. Static metrics covered the complexity and the criticality within an integrated component. The static metrics suit includes the CPD metric, CID metric in the entire system. They also define a set of criticality criteria for component integration. By recognizing a complex and/or critical component, it should give a contribution on the effort and cost estimation.

SIGNIFICANCE:
For CPD metrics the number of operations and number of components in a component assembly are taken into account. As per model UCRS, when the number of components increases, density increases. A higher density means a higher complexity, which will force the developer to spend more effort and risk assessment on the system. Therefore more resources are needed to complete the project.  Number of Actual Interaction CID Registration-system = Number of total Interaction CID Registration-system = 7/11, which is 0.3636 The result for CID Registration-system which is 0.3636 is calculated by the CAME tool [Pandey, Shareef, 2013].

SIGNIFICANCE:
For CID metrics the number of Actual Interaction and Number of total Interaction in a component assembly are taken into account. As per model UCRS, there is a risk in submitting and receiving an event, as events have to be handled with care for correct processing. The main problem arises when measuring the density of interactions in a component. When the density of interaction increases, complexity increases.
The CIID metric measures the ratio of actual number of incoming interactions to the maximum available incoming interactions in a component, which can be obtained from design document. Incoming interaction is defined as a received interface that is required in a component or a received event that arrives at a component. The CAID metric is a sum of interaction densities for each component divided by the number of components in software system. CAID is calculated based on previous values can also be obtained from design documents.
Where, ∑ CID n represents the sum of interaction densities for components 1...n; # components represents the number of existing components in the software system. There are 5 components, which have "provided" and "required" interfaces. The components "Course Management", "Term Management", "Person Management", "Billing System" provided interfaces are being consumed, where as "Registration System" is having 7 provided interfaces, but they are not being consumed. SIGNIFICANCE: As per model UCRS, It evaluates the complexity of the entire component assembly. The value will be valuable to assess the whole system interaction. The low value of CAID indicates low interactions, which also means lower complexity.

III. CRITICALITY METRICS
Criticality metrics used for a critical component that binds a system, consisting of assembly of components. For a software tester, this component requires substantial testing effort. Every possible scenario for this critical component has to be tested, particularly if it is a base component, so that any incorrect operations are not inherited by the subcomponents. To identify the critical components, or the circumstances that make a component critical, four metrics are used and they characterize the circumstances that make a component critical. These metrics are Link Criticality, Bridge Criticality, Inheritance Criticality and Size Criticality metrics.

CRIT bridge = # bridge_component
Where # bridge_component represents the number of bridge components. A bridge component may be defined as a component which links two or more components/ application. If there is a defect in bridge, the whole application might malfunction. More number of bridge components means more chances of failure. There are no components acting as bridge, because all the four components "Course Management", "Term Management", "Person Management", "Billing System" are providing interfaces directly to component "Registration System". So, the component "Registration System" for CRIT bridge result is zero.
SIGNIFICANCE: As per model UCRS, to identify a bridge component, an importance weight should be placed for each link by the developer based on their experience. This component has to be identified, since a defective bridge component has a high probability to prevent the functioning of the entire application. The more the number of bridge components implies, the more the chances for failure.

 METRIC 8 -INHERITANCE CRITICALITY METRIC (CRIT INHERITANCE )
Inheritance Criticality metric is defined as the number of components, which become root or base for other inherited components. This metric can be obtained at early stage because those components are identified which becomes root or base for other inherited components. CRIT inheritance = # root _ component Where # root_component represents the number of root components which has inheritance. It is the number of components which act as a parent/root/base for other components.
All the four components "Course Management", "Term Management", "Person Management", "Billing System" are providing interfaces directly to component "Registration System", which also has provided interfaces, which are not being consumed.  figure 6 and 7. The Size Criticality Metric helps in detecting components whose size value exceeds a threshold value, which is defined by Narasimhan and Hendradjaya, components being black box in nature, only their interfaces can be accessed, which contain operations. These are counted to check the threshold value. So, the value of this metric is 1 if it exceeds the threshold value for a particular Component. If it exceeds the value then that particular component is considered "critical" otherwise it is "simple". If the component does not contains any operations than it is displayed as "Not Available". Here the interface "ITermMgt" of component "Term Management" is having maximum operations i.e. 3, so it does not exceed threshold value and is considered "simple".

 METRIC 10 -# CRITICALITY METRIC
The #Criticality Metric (CRIT all ) is defined as the sum of all critical metrics. CRIT all = CRIT link + CRIT bridge + CRIT inheritance +

CRIT size
By totalling the number of components that have link, bridge, inheritance and size criticality, we obtain the criticality level of the component assembly. The value of CRIT is compared to a threshold value in order to identify the criticality level of a component assembly. For instance, if the threshold value for CRIT link , CRIT bridge , CRIT inheritance , and CRIT size equal 5, then the threshold value for CRIT all is 20. By experimenting with more empirical data, a more accurate threshold value could be produced.

IV. METHODOLOGY
The objective of this paper is an assembly of components for a system to be designed at early stage. In this research work, by using open source UML "ArgoUML", a tool using NetBeans has been developed, named as "CAME" (Component Assembly Metrics Extractor), this tool helps in extracting the static complexity metrics proposed by Narasimhan and Hendradjaya [Narasimhan and Hendradjaya, 2007]. Using the ArgoUML tool, the model given in is designed creating component artifacts through Deployment diagram option, the XMI 1.2 file is generated with the help of Export XMI option (ArgoUML using Netbeans XMI Writer version 1.0), which is then parsed for extracting information related to various metrics in a component assembly for component-based systems using a Java based software tool. The parser parses the XMI file, which contains information about all the components integrated into the system, this open source tool assigns a unique XMI identifier (UUID) to flag user designed model components. For example, in this system, a student registers for classes. Once given access, the students may select a term and build a class schedule from the offered classes. The system passes information about a student's schedule to the billing system. A student can also register, add, or drop a course. An instructor may use the registration system to print a student class list and to submit grades for her/his class. The administrator may maintain student and teacher information. This model provides an overall view of the system and helps to demonstrate the extraction of existing component assembly complexity metrics. With the help of CAME tool a number of facts related to component assembly can be derived through XMI file, which helps the developer in analyzing the different aspects of components and assembly information. This information is displayed through User Interface. Through this user interface a developer can learn about number of components, their interfaces and the operations available in an interface of a component assembly. Component names are displayed and after selecting a particular component its interfaces: Provided (Abstraction) and Required (Dependency) can be displayed. Similarly the details of operations of a particular interface can be displayed by selecting the interface. The component-"Registration System" has a provided interface "IMakeSchedule", this interface consists of four operations, the same information is provided using CAME tool. In this work static metrics are used for integration of software components, complexity metrics for UML Component-based System Specification (CBSS) and interface complexity metrics in a component assembly proposed by different authors for component-based systems using UML artifacts are derived. These metrics are derived by developing a tool named "CAME" (Component Assembly Metrics Extractor) in Netbeans which parses through the XMI file (XML Meta Data Interchange) generated by UML tool and produces different component metrics through graphic user interface. These metrics will help the software developer in attaining more information at early stage, making the system more stable, better and efficient.

V.
COMPONENT ASSEMBLY METRICS EXTRACTOR (CAME) TOOL Other metrics related to Component-based systems can be included in enhanced version of the tool proposed.