Software Metrics

 

 

6.1 Software metrics: what & why? 

 6.2 Token count 

 6.3 Data structure metrics 

 6.4 Information flow metrics 

 6.5 Metrics analysis

Data Structure Metrics 

Essentially the need for software development and other activities are to process data. Some data is input to a system, program or module; some data may be used internally, and some data is the output from a system, program, or module.  

....Example

That's why an important set of metrics which capture in the amount of data input, processed in an output form software. A count of this data structure is called Data Structured Metrics. In these concentrations is on variables (and given constant) within each module & ignores the input-output dependencies

There are some Data Structure metrics to compute the effort and time required to complete the project. There metrics are: 

1. The Amount of Data. 

2. The Usage of data within a Module. 

3. Program weakness. 

4. The sharing of Data among Modules.

1. The Amount of Data: To measure the amount of Data, there are further many different metrics, and these are: 

• Number of variable (VARS): In this metric, the Number of variables used in the program is counted.  

• Number of Operands (η2 ): In this metric, the Number of operands used in the program is counted. η2 = VARS + Constants + Labels 

• Total number of occurrence of the variable (N2): In this metric, the total number of occurrence of the variables are computed 

2. The Usage of data within a Module: The measure this metric, the average numbers of live variables are computed. A variable is live from its first to its last references within the procedure.

3. Program weakness: Program weakness depends on its Modules weakness. If Modules are weak(less Cohesive), then it increases the effort and time metrics required to complete the project.

4.There Sharing of Data among Module: As the data sharing between the Modules increases (higher Coupling), no parameter passing between Modules also increased, As a result, more effort and time are required to complete the project. So Sharing Data among Module is an important metrics to calculate effort and time.

Information Flow Metrics

The other set of metrics we would live to consider are known as Information Flow Metrics. The basis of information flow metrics is found upon the following concept the simplest system consists of the component, and it is the work that these components do and how they are fitted together that identify the complexity of the system. The following are the working definitions that are used in Information flow:  

•  Component: Any element identified by decomposing a (software) system into it's constituent's parts. 

•  Cohesion: The degree to which a component performs a single function. 

•  Coupling: The term used to describe the degree of linkage between one component to others in the same system.

Information Flow metrics deal with this type of complexity by observing the flow of information among system components or modules. This metrics is given by Henry and Kafura. So it is also known as Henry and Kafura's Metric.

This metrics is based on the measurement of the information flow among system modules. It is sensitive to the complexity due to interconnection among system component. This measure includes the complexity of a software module is defined to be the sum of complexities of the procedures included in the module. A process contributes complexity due to the following two factors. 

• The complexity of the procedure code itself. 
• The complexity due to the procedure's connections to its environment. The effect of the first factor has been included through LOC (Line Of Code) measure. For the quantification of the second factor, Henry and Kafura have defined two terms, namely FAN-IN and FAN-OUT.

• FAN-IN: FAN-IN of a procedure is the number of local flows into that procedure plus the number of data structures from which this procedure retrieve information. 
• FAN -OUT: FAN-OUT is the number of local flows from that procedure plus the number of data structures which that procedure updates.
• Procedure Complexity = Length * (FAN-IN * FANOUT)**2 

Case Tools For Software Metrics

Many CASE tools (Computer Aided Software Engineering tools) exist for measuring software. They are either open source or are paid tools. Some of them are listed below: 

• Analyst4j tool is based on the Eclipse platform and available as a stand-alone Rich Client Application or as an Eclipse IDE plug-in. It features search, metrics, analyzing quality, and report generation for Java programs. 

• CCCC is an open source command-line tool. It analyzes C++ and Java lines and generates reports on various metrics, including Lines of Code and metrics proposed by Chidamber & Kemerer and Henry & Kafura. 

• Chidamber & Kemerer Java Metrics is an open source command-line tool. It calculates the C&K object-oriented metrics by processing the byte-code of compiled Java. 

• Dependency Finder is an open source. It is a suite of tools for analyzing compiled Java code. Its core is a dependency analysis application that extracts dependency graphs and mines them for useful information. This application comes as a commandline tool, a Swing-based application, and a web application. 

• Eclipse Metrics Plug-in 1.3.6 by Frank Sauer is an open source metrics calculation and dependency analyzer plugin for the Eclipse IDE. It measures various metrics and detects cycles in package and type dependencies. 

• Eclipse Metrics Plug-in 3.4 by Lance Walton is open source. It calculates various metrics during build cycles and warns, via the problems view, of metrics 'range violations'. 

• OOMeter is an experimental software metrics tool developed by Alghamdi. It accepts Java/C# source code and UML models in XMI and calculates various metrics. 

• Semmle is an Eclipse plug-in. It provides an SQL like querying language for object-oriented code, which allows searching for bugs, measure code metrics, etc

...Comming Soon