________________________________________
Abstract: Object-oriented technology has rapidly accepted as the preferred way for large-scale system design. With the help of this advanced technology we can develop software product of higher quality and lower maintenance cost. It is evident that the available traditional software metrics are inadequate for case of object-oriented software , a set of new object oriented software metrics came into existence.The software test metrics are the key element of quality driven testing. They help in ensuring that whether the software is appropriate or not. Result shows,The best metrics suite is CK metric suite which covers almost all the features which should be there in a software quality assurance testing.Measurement of software complexity and quality has been of great interest to researchers in software engineering for some time. Software complexity has been shown to be one of the major contributing factors to the cost of developing and maintaining software. In this research paper we investigate several object oriented metrics proposed by various researchers. These object oriented metrics are then applied to several java programs to analyze the complexity of software product. Software Reliability, Readability, Maintainability ,Reusability can be calculated based on the values of such metrics. These results are used for improving overall quality of the code and helping in reduction of maintenance cost.
Key words: General Quality Metrics, Measurement Tools, Object Oriented Metrics, Software complexity.
________________________________________
1. Introduction
1.1 SOFTWARE ENGINEERING
Software Engineering is an Engineering discipline which is concerned with all aspects of software production from the early stages of system specification through to maintain the system after it has gone into use. Software Engineering methods provide the techniques for building software. Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing and support. Software engineering tools provide automated or semi-automated support for the process and the methods.
1.2 SOFTWARE DEVELOPMENT PROCESS
Software development can also be defined as application development, software design, designing software, software application development, enterprise application development, or platform development is the development of a software product. It is the term which includes all that is involved between the conception of the desired software through to the final manifestation of the software, ideally in a planned and structured process. Therefore, software development may include research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.
There are several different approaches to software development, much like the various views of political parties toward governing a country. Some take a more structured, engineering-based approach to developing business solutions, whereas others may take a more incremental approach, where software evolves as it is developed piece-by-piece.
1.3 SOFTWARE QUALITY METRICS
Software Metric is a measure of some property of a piece of software or its specifications. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments.
Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product.
Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability, the degree to which the software was produced correctly.
Structural quality is evaluated through the analysis of the software inner structure, its source code, in effect how its architecture adheres to sound principles of software architecture. In contrast, functional quality is typically enforced and measured through software testing. Software quality measurement quantifies to what extent a software or system rates along each of these five dimensions. An aggregated measure of the software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum is supplemented by the analysis of “critical programming errors” that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements.
1.3.1 METRICS APPROACH
A metrics approach to facilitate the management of sub-contracted or outsourced development and maintenance has been successfully used by many organizations. For example, the U.S. Healthcare Finance Administration uses metrics to manage multiple contractors making and testing enhancements to regional versions of Medicare/Medicaid administration software, with a focus on the effectiveness of testing efforts. And various U.S. Department of Defence projects have used the approach to manage contractors developing weapons systems, with a focus on the quality of newly developed software.
The overall purpose of this document is to provide answers to several basic questions relating to the management of sub-contracted or outsourced development and maintenance:
‘ What is the metrics approach to managing sub-contractors’? What is the quality of the code that has been developed by the sub-contractor’? How well tested was the code before delivery by the sub-contractor’? How are the ongoing maintenance costs related to the code quality’? What is the role of automated tools’? What is the role of visualization?
1.3.2 BENEFITS OF SOFTWARE METRICS
The knowledge on how to use certain metrics to manage the process of using sub-contractors on a project is obtained using software metrics. Specifically defining the different types of sub-contractors, it is understood how to approach the three very differing management scenarios. In addition, the use of code metrics provides a clearer insight into what the customer might really be paying for when the code is in, or moves downstream in the product life-cycle to the maintenance phase.
The benefits of using Software Metrics are:
‘ Without proper code metrics, only a complete picture of what is being produced could not be obtained.
‘ Without metrics automation using a tool such as McCabe IQ, user will face a complex process in focusing on the potentially problematic areas of the code base.
‘ Without metrics based code visualization using a tool such a McCabe IQ, user will face a complex process in identifying and reviewing the code in the problematic areas of the code base.
‘ Without a metrics-reporting tool such as McCabe IQ, user will face a complex task in managing the information that any analysis of the code base will provide.
‘ Without the use of industry-accepted metrics and their associated thresholds for code, the user will face an uphill task in setting the expectations of own management chain.
1.4 APPLICATIONS OF THE DOMAIN
Software quality objectives cover a variety of techniques and measurements, including gathering code metrics, enforcing coding rules, and proving the absence of run-time errors. The guide also takes into account the origin of the code, its stage in the software life cycle, and the safety aspects of the application. Automotive teams are now applying the Software Quality Objective document as a baseline for their own code development and verification process. Quality assurance for automotive systems can require different types of verification activities throughout the development process.
‘ Early verification focuses on evaluating intermediate software builds and removing defects at coding time. This represents an emerging trend because performing verification early in the process can improve overall quality and reduce development time.
‘ Post-production verification focuses on evaluating final build quality or finding defect root causes after the product is complete. This is the most common approach to automotive system verification.
Shifting from post-production quality assurance to early verification can require major process and tool changes. To enable incremental adoption of these changes, automotive OEMs and suppliers developed a practical guide, the Software Quality Objectives document.
1.5 PROBLEM STATEMENT
Formal specifications have a variety of applications, including testing, maintenance, optimization, refectory, documentation, and program repair. Software Maintenance in Software Engineering is the modification of a Software product after delivery to correct the faults and to improve performance or other attributes. Without knowing the correct notion of the program behavior it is difficult to correct the code. However, such specifications are difficult for human programmers to construct and verify manually, and existing automatic specification miners that discover two-state temporal properties have prohibitively high false positive rates. The existing miners have low accuracy rate.[1]
1.6 OBJECTIVE OF THE PAPER
The main objective of the paper is to find the accuracy of the software using software metrics. The quality of the code is measured by extracting additional information from the software engineering process and using information from code that is more likely to be correct, as well as code that is less likely to be correct. Various software metrics are used to find the quality metrics of the specific software.
Figure:
2. Quality Metrics
2.1 GENRAL QUALITY METRICS
1. Code Churn :-
It use version control repositories to record the time between the current revision and the last revision for each line of code in wall clock hours.
2. Author Rank :-
The rank of an author is defined as the percentage of all changes to the repository ever committed by that author. It record the rank of the last author to touch each line of code.
3. Code Clones :-
It express the measure of code cloning for a given code fragment as the product of the length of the code segment and the number of times it has been copied. It use the open-source PMD toolkit’s clone detector to track likely copy-paste repetition.
4. Code Readability :-
The metric uses textual source code features’such as number of characters, length of variable names, or number of comments’to predict how humans would judge the code’s readability. Readability is defined on a scale from 0 to 1, inclusive, with 1 describing code that is highly readable. More readable code is less likely to contain errors.
2.2 METRICS SUITE FOR OO DESIGN
CK metrics: The important component of process improvement is the ability to measure the process [3]. Chidamber and Kemerer proposed a suite of theoretically grounded metrics to approximate the complexity of an object-oriented design. The following five metrics apply to a particular class (i.e., a set of methods and instance variables.
2.2.1 Weighted Methods per class( WMC)
It is the total Number of methods in a class, weighted by a user-specified complexity metric. It is calculated by the formula WMC = ‘ni=1 Ci
2.2.2 Depth of inheritance tree (DIT)
The Maximal length from the class to the root of the type inheritance tree is the Depth of Inheritance.
2.2.3 Number of children (NOC)
It is the total number of classes that directly extend the specified class.
2.2.4 Coupling between objects (CBO)
It denotes the Number of other objects to which the class is coupled. Class A is coupled to Class B if one of them calls methods or references an instance variable defined in the other.
2.2.5 Response for a class (RFC)
Size of the response set, defined as the union of all methods defined by the class and all methods called by all methods in the class.
3. Related work
3.1. Prediction of Reliability
The measure of reliability guarantees whether software under development has been implemented accurately. Unlike other engineering and science disciplines, absolute measurements like mass, velocity are uncommon in software engineering. Metrics are used to evaluate the process and the product(Software) in its various stages against various standards and norms.[12]
Threshold is a point beyond which there is a change in the manner a program executes. Based on these values of the threshold, threshold for software reliability can be estimated correctly. This will help the designers and developers to check the product against the threshold of reliability, if it doesn’t fall within the range, then the decision for redesign has to be made in order to meet the specifications.
The IEEE defines software reliability as ‘The ability of a system or component to perform its required
functions under stated conditions for a specified period of time’. Software reliability is the probability of failure free software operation which directly or indirectly affects the system reliability and it is very different from hardware reliability in that it reflects the design perfection rather than manufacturing perfection. Obtaining reliability estimates early in the development process can help determine if the software system is on track to meet its reliability goals and therefore increase management effectiveness and efficiency.[12]
3.2.Calculating threshold of Reliability
RT(Max) = k*(1/(wt(WMC)+wt(DIT)+wt(RFC)+wt(LOCM)+wt(CBO)) + (log(U-Lt(NOC)))2
RT(Min) = k*(1/(wt(WMC)+wt(DIT)+wt(RFC)+wt(LOCM)+wt(CBO)) + (log(L-Lt(NOC)))2
Accordingly
Let us assume k = unity = 1
RT(Max) =1*(1/(1+1+1+1+1)) + (log(3))2 = 0 .4276
RT(Min) = 1*(1/(2+2+2+2+2)) + (log(1))2 = 0.1000
Therefore we state the Threshold for Reliability of software based on the relationship of Reliability and
CK Metrics lies between 0.6777 and .10000 [12]
0.1000 < RT < 0.4276
3.3.Relation between CK metrics and Maintainability
The RFC is the number of all the methods that can potentially be executed (directly or indirectly) in response to a message to an object of that class or by some method in the class. This includes all methods accessible within class hierarchy.
According to CK metrics, a class with large RFC indicates the class is more complex, and as we know complexity is inversely proportional to maintainability. It suggests that larger RFC indicates that class is harder to maintain. RFC increases complexity and complexity decreases maintainability.
3.4.Reusability and CK metrics
Combination of two or more metrics or we can say group of metrics make impact on reusability of software code. Deeper a particular class is in the hierarchy, the greater the potential for reuse of inherited methods . It states that reusability of a class increases with increase in DIT of a class. So DIT has positive impact on reusability of a class. A moderate value for NOC indicates scope for reuse. Up to particular threshold value NOC has positive impact on reusability of a class.
Therefore the reusability of a class increases with the increase in combination of DIT and NOC of a class. So DIT + NOC have positive impact on reusability of a class. Excessive coupling indicates weakness of class encapsulation and may inhibit reuse. It indicates that coupling has negative impact on reusability of a class. High LCOM increases complexity, thereby increasing likelihood of errors during the development process. The class should probably split into two or more smaller classes. It indicates that cohesion has negative impact on reusability of a class.[13]
Therefore CBO +LCOM have negative impact on reusability of a class. The large no. of methods in a class, the greater the potential impact on children. Classes with large no. of methods are likely to be more application specific, limiting the possibility of reuse. So WMC has negative impact or reusability of a class. The larger the no. of methods that can be invoked from a class through message, the greater the complexity of the class. So RFC has negative impact or reusability of a class. Therefore the reusability of a class decreases with the increase in combination of WMC and RFC of a class. So WMC+RFC have negative impact on reusability of a class.[13]
4. Result and Discussion
4.1. Result calculation
Projects
Properties
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10
Lines of Code 344 545 560 470 877 800 754 1200 483 960
Number of Comments 23 100 250 350 400 200 144 400 45 554
McCabe's Complexity 3 2 8 7 4 12 3 4 2 8
WMC 41 80 19 12 28 26 12 28 45 43
RFC 15 14 16 15 32 20 15 36 67 32
DIT 3 3 2 2 5 2 2 5 6 6
LOCM 1 1 2 2 3 2 2 3 4 3
CBO 3 4 4 2 5 1 2 5 4 6
NOC 14 9 3 3 2 2 1 2 12 9
Readability 0.0697 0.1834 0.446 0.744 0.456 0.4 0.19 0.33 0.093 0.577
Reliability 1.3905 0.9939 0.3109 0.4276 0.1675 0.2572 0.2 0.1675 1.2062 0.9661
Maintainability 0.0666 0.0714 0.0625 0.0666 0.0312 0.05 0.0666 0.0277 0.0149 0.0312
Regression 8.03 -20.67 19.83 22.88 8.23 9.44 21.95 6.78 -12.86 1.82
Complexity 3 2 8 7 4 12 3 4 2 8
These metrics were calculated and tested on several java programs and and following points are observed
1 .The WMC metric acts as a predictor of how much time and effort is required to develop and maintain the whole class. The larger the number of methods in a class, the greater the potential impact on children; children inherit all of the methods defined in the parent class. Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse. It was observed that an increase in the average WMC increases the density of bugs and defects and decreases overall quality and reusability.
2.The deeper a class is in the hierarchy, the more methods it is likely to inherit, making it more complex. Deep trees as such indicate greater design complexity. As a positive factor, deep trees promote reuse because of method inheritance. As per our observations, java programs have intermediate value for DIT metric.
3 .Since RFC specifically includes methods called from outside the class, it is also a measure of the communication between the class and other classes. A large RFC has been found to indicate more faults. Classes with a high RFC are more complex and harder to understand, and therefore harder to maintain. Testing and debugging of such classes is complicated. A worst case value for possible responses will assist in appropriate allocation of testing time. A study of various java programs suggests that an increase in RFC increases the density of bugs and decreases overall quality.
4 High NOC indicates high reuse, since inheritance is a form of reuse. A large number of children (high NOC) may also mean improper abstraction of the parent class. If a class has too many children, it may indicate misuse of sub-classing. A class with many children may also require more intensive testing. High NOC has been found to indicate fewer faults. This may be due to high reuse, which is desired. In java the value of this metric depends on program to program. All classes do not have the same number of sub-classes. However, it is observed that for better results, classes higher up in the hierarchy should have more sub-classes then those lower down.
5.Total Impact on Reusability-
We observed that, some group of metrics have positive impact on the calculation of the reusability and some have negative impact. As we observed in result DIT+NOC have positive impact and CBO+LCOM and WMC+RFC have negative impact on it. We can calculate total impact of metrics on reusability by adding positive and negative impact.
Total impact=Positive impact + Negative impact
Graph of Reliability for various projects
5. Conclusion
Software developers can benefit from an early estimate regarding the quality of their product as field quality information is often available late in the software lifecycle to affordably guide corrective actions. Identifying early indicators of field quality is very important. Moreover it is very necessary and effectively reduces the cost of the software and also the maintenance time. The code quality is measured by extracting additional information from the software engineering process and using information from code that is more likely to be correct. The quality metrics is used for this purpose.
The software is tested with unstructured code which results in low value of accuracy. It indicates that the input given was poor quality software. Thus the software is checked for negative results. Software Reliability, Readability, Maintainability ,Reusability can be calculated based on the values of such metrics. These results are used for improving overall quality of the code and helping in reduction of maintenance cost.
Acknowledgment
In our endeavor to achieve the success in completing paper on ' Measuring Code Quality to Improve Specification Mining ' in the Final Year Engineering in Computer Engineering. We greatly thankful to the people without whose assistance, guidance and efforts we would not be able to complete out paper successfully. we express heartfelt gratitude to our guide, Prof. D. B. Hanchate who through his experience, encouragement and constant guidance helped us to shape our paper to the present stage without his help our paper could not be completed. Finally, I would like to thanks to respected Prof. G. J. Chhajed (Head Of Computer Dept.) and we also equally indebted to our coordinator Prof. S. A. Shinde and Principal Dr. S. B. Deosarkar for their valuable help whenever needed , college's teaching and non-teaching staff of my department for co-ordinating with us.
References
(Book)
[1] C. Le Goues and W.Weimer, " Measuring Code Quality to Improve Specification Mining," IEEE Transactions on Software Engineering, VOL. 38, NO. 1,pp.175-190,2012.
[2] C. Le Goues and W. Weimer, " Specification Mining with Few False Positives ," Proc.
Int. Conf. Tools and Algorithms for the Construction and Analysis of Systems, pp.292-306, 2009.
[3] S.R. Chidamber and C.F. Kemerer, " A Metrics Suite for Object Oriented Design,"
IEEE international conference on data mining 2008. pp. 150-159.
[4] G. Ammons, R. Bodik, and J.R. Larus, " Mining Specifications ," Proc. ACMSIGPLAN-SIGACT Symp. Principles of Programming Languages, pp. 4-16, 2002.
[5] W. Weimer and G.C. Necula, " Mining Temporal Specifications for Error Detection ,"
Proc. Int. Conf. Tools and Algorithms for the Construction and Analysis of Systems,pp. 461-476, 2005.
[6] J. Yang, D. Evans, D. Bhardwaj, T. Bhat, and M. Das, "Perracotta: Mining Temporal API Rules from Imperfect Traces," Proc. Int. Conf. Software Eng., pp. 282-291, 2006.
[7] D.R. Engler, D.Y. Chen, and A. Chou, "Bugs as Inconsistent Behavior: A General Approach to Inferring Errors in Systems Code,"Proc. Symp. Operating System Principles, pp. 57-72, 2001.
[8] M.-H. Tang, M.-H. Kao, and M.-H. Chen, "An Empirical Study on Object-Oriented Metrics,"Proc. Int. Symp. Software Metrics, pp. 242-249, 1999.
[9] T.J. McCabe, "A Complexity Measure,"IEEE Trans. Software Eng., vol. 2, no. 4, pp.308-320, Dec. 1976.
[10] M. Halstead, "Elements of Software Science,"Elsevier, 1977.
[11] P.G. Hamer and G.D. Frewin, "M.H. Halsteada'.s Software Science - A Critical Examination,"Proc. Inta'.l Conf. Software Eng., pp. 197- 206, 1982.
[12]Johny Antony P ,'Predicting Reliability of Software Using Thresholds of CK Metrics'.
[13] Brij Mohan Goel, Pradeep Kumar Bhatia ,'Analysis of Reusability of Object-Oriented System using CK Metrics'
...(download the rest of the essay above)