Showing papers on "Halstead complexity measures published in 2010"

Evaluating Software Complexity Measures

Abstract: A set of properties of syntactic software complexity measures is proposed to serve as a basis for the evaluation of such measures. Four known complexity measures are evaluated and compared using these criteria. This formalized evaluation clarifies the strengths and weaknesses of the examined complexity measures, which include the statement count, cyclomatic number, effort measure, and data flow complexity measures. None of these measures possesses all nine properties, and several are found to fail to possess particularly fundamental properties; this failure calls into question their usefulness in measuring synthetic complexity. >

Understanding the impact of code and process metrics on post-release defects: a case study on the Eclipse project

Abstract: Research studying the quality of software applications continues to grow rapidly with researchers building regression models that combine a large number of metrics. However, these models are hard to deploy in practice due to the cost associated with collecting all the needed metrics, the complexity of the models and the black box nature of the models. For example, techniques such as PCA merge a large number of metrics into composite metrics that are no longer easy to explain. In this paper, we use a statistical approach recently proposed by Cataldo et al. to create explainable regression models. A case study on the Eclipse open source project shows that only 4 out of the 34 code and process metrics impacts the likelihood of finding a post-release defect. In addition, our approach is able to quantify the impact of these metrics on the likelihood of finding post-release defects. Finally, we demonstrate that our simple models achieve comparable performance over more complex PCA-based models while providing practitioners with intuitive explanations for its predictions.

A survey on metric of software complexity

Abstract: With the evolution of the software development, the scale of the software is increasingly growing to the extent that we cannot hand it easily. Some metrics are proposed to measure the complexity of software in last a few years. This article aims at a comprehensive survey of the metric of software complexity. Some classic and efficient software complexity metrics, such as Lines of Codes (LOC), Halstead Complexity Metric (HCM) and Cyclomatic Complexity Metric (CCM), are discussed and analyzed first. Then, some other approaches driven from above classic metrics are also discussed. The comparison and the relationship of these metrics of software complexity are also presented.

A Hybrid Set of Complexity Metrics for Large-Scale Object-Oriented Software Systems ∗

Abstract: Large-scale object-oriented (OO) software systems have recently been found to share global network characteristics such as small world and scale free, which go beyond the scope of traditional software measurement and assessment methodologies. To measure the complexity at various levels of granularity, namely graph, class (and object) and source code, we propose a hierarchical set of metrics in terms of coupling and cohesion — the most important characteristics of software, and analyze a sample of 12 open-source OO software systems to empirically validate the set. Experimental results of the correlations between cross-level metrics indicate that the graph measures of our set complement traditional software metrics well from the viewpoint of network thinking, and provide more effective information about fault-prone classes in practice.

A survey of dynamic software metrics

Abstract: Software metrics help us to make meaningful estimates for software products and guide us in taking managerial and technical decisions. However, conventional static metrics have been found to be inadequate for modern object-oriented software due to the presence of object-oriented features such as polymorphism, dynamic binding, inheritance and unused code. This fact motivates us to focus on dynamic metrics in place of traditional static metrics. Moreover, dynamic metrics are more precise than static metrics as they are able to capture the dynamic behaviour of the software system during measurement. These dynamic metrics are usually obtained from the execution traces of the code or from the executable models. In this paper, advantages of dynamic metrics over static metrics are discussed and then a survey of the existing dynamic metrics is carried out. These metrics are characterized into different categories such as dynamic coupling metrics, dynamic cohesion metrics. Towards end of the paper, potential research challenges and opportunities in the field of dynamic metrics are identified.

Assessing traditional and new metrics for object-oriented systems

Abstract: We present an extensive analysis of software metrics for 111 object-oriented systems written in Java. For each system, we considered 18 traditional metrics such as LOC and Chidamber and Kemerer metrics, as well as metrics derived from complex network theory and social network analysis. These metrics were computed at class level. We also considered two metrics at system level, namely the total number of classes and interfaces, and the fractal dimension. We discuss the distribution of these metrics, and their correlation, both at class and at system level. We found that most metrics follow a leptokurtotic distribution. Only a couple of metrics have patent normal behavior while three others are very irregular, and even bimodal. The statistics gathered allow us to study and discuss the variability of metrics along different systems, and to devise a roadmap for further research.

An empirical study of social networks metrics in object-oriented software

Abstract: We study the application to object-oriented software of new metrics, derived from Social Network Analysis. Social Networks metrics, as for instance, the EGO metrics, allow to identify the role of each single node in the information flow through the network, being related to software modules and their dependencies. These metrics are compared with other traditional software metrics, like the Chidamber-Kemerer suite, and software graph metrics. We examine the empirical distributions of all the metrics, bugs included, across the software modules of several releases of two large Java systems, Eclipse and Netbeans. We provide analytical distribution functions suitable for describing and studying the observed distributions. We study also correlations among metrics and bugs. We found that the empirical distributions systematically show fat-tails for all the metrics. Moreover, the various metric distributions look very similar and consistent across all system releases and are also very similar in both the studied systems. These features appear to be typical properties of these software metrics.

A metrics suite for evaluating agent-oriented architectures

Abstract: The Multi-agent Systems (MASs) paradigm continues to consolidate itself as a new branch of software engineering. Traditional software engineering strongly recommends to apply metrics in software developments. However, several research groups of experts in agent-oriented software engineering agree that classical software metrics and object-oriented metrics cannot directly measure the quality of MAS architectures. For this reason, this work proposes a suite of metrics to measure certain quality attributes of MAS architectures, considering agents and their organization. Most of these metrics are inspired by object-oriented metrics but they are adapted to agent-oriented concepts. Proposed metrics are validated by the application to four problem domains and eight architectures.

Complexity Metrics for Executable Business Processes

Abstract: In this study, seven metrics are proposed for measuring the complexity of Executable Business Processes (EBP). The metrics are either derived from existing business process metrics or adapted from software metrics. Evaluation was carried out in three case studies with the goal of finding out if the metrics are theoretically sound and at the same time intuitional. In case 1, metrics values were computed from three processes and then analyzed to check whether they agree with reality. In case 2, the metrics were grouped into two categories of length and complexity and then separately checked for their conformance to Briand’s framework. In case 3, all the metrics were treated under one complexity category and then checked for their conformance to Weyuker’s properties. Results indicate that the new metrics are intuitional and are good if used in their respective categories, or when used together to complement each other in order to give a fuller view of process complexity.

Empirical Analysis of CK & MOOD Metric Suit

Abstract: With the rise of the OO paradigm has come the acceptance that conventional software metrics are not adequate to measure object-oriented systems. This has inspired a number of software practitioners and academics to develop new metrics that are suited to the OO paradigm. The MOOD metrics have been subjected to much empirical evaluation, with claims made regarding the usefulness of the metrics to assess external attributes such as quality and maintainability. We evaluate the MOOD metrics on a theoretical level and show that any empirical validation is premature due to the majority of the MOOD metrics being fundamentally flawed. The metrics either fail to meet the MOOD team's own criteria or are founded on an imprecise, and in certain cases inaccurate, view of the OO paradigm. One of the suite of OO design measure was proposed by Chidamber and Kemerer. The author of this suite of metrics claim that these measure can aid users in understanding object oriented design complexity and in predicting external software qualities such as software defects, testing, and maintenance effort. Use of the CK set of metrics and other complexity measures are gradually growing in industry acceptance. This is reflected in the increasing number of industrial software tools, such as Rational Rose, that enable automated computation of these metrics. Even though this metric suite is widely, empirical validations of these metrics in real world software development setting are limited. Various flaws and inconsistencies have been observed in the suite of six class based metrics. We validate some solutions to some of these anomalies and clarify some important aspects of OO design, using Six projects in particular those aspects that may cause difficulties when attempting to define accurate and meaningful metrics. These suggestions are not limited to the MOOD and CK metrics but are intended to have a wider applicability in the field of OO metrics.

Software metrics in static program analysis

Abstract: Software metrics play an important role in the management of professional software projects. Metrics are used, e.g., to track development progress, to measure restructuring impact and to estimate code quality. They are most beneficial if they can be computed continuously at development time. This work presents a framework and an implementation for integrating metric computations into static program analysis. The contributions are a language and formal semantics for user-definable metrics, an implementation and integration in the existing static analysis tool GOANNA, and a user-definable visualization approach to display metrics results. Moreover, we report our experiences on a case study of a popular open source code base.

Comparative Study of Complexities of Breadth- First Search and Depth-First Search Algorithms using Software Complexity Measures

Abstract: In this study, two different software complexity measures were applied to breadth-first search and depth-first search algorithms. The intention is to study what kind of new information about the algorithm the complexity measures (Halstead's volume and Cylomatic number) are able to give and to study which software complexity measure is the most useful one in algorithm comparison. The results clearly show that with respect to Program Volume, breadth-first search algorithm is best implemented in Pascal language while depth-first search is best implemented in C language. The values of Program Difficulty and Program Effort indicate that both the algorithms are best implemented in Pascal language. Cyclomatic number is the same for both algorithms when programmed in Visual BASIC (i.e. 6).

Early estimation of software complexity using requirement engineering document

Abstract: There has been a continuous effort to estimate software complexity but very little established methods exist that can estimate the complexity of the software before it is written. Since a high quality Software Requirement Specification (SRS) is a pre requisite for high quality software, this work attempts to empirically demonstrate that the complexity of the code can be determined based on its IEEE software requirement specification document (IEEE 830-1998). Existing complexity measures established are based on the code and the cognitive metrics value of the software. This may require recodingleading to loss of time and cost. Considering the shortcoming of code-based approaches, our proposed approach is able to compute the complexity of yet-to-be-written software immediately after freezing the requirement in the Software development Lifecycle (SDLC) process. The proposedcomplexity measure compares well with established complexity measures like Halstead, Mc Cabe, KLCID, CFS and CICM. Results obtained show that the complexity values are comparable with other established measures. The robustness of our complexity measure is established by evaluating our measure against Weyuker properties.

Problems adopting metrics from other disciplines

Abstract: In this paper, we argue that metrics validation approaches used in software engineering are problematic. In particular, theoretical validation is not rigorous enough to detect invalid metrics and empirical validation has no mechanism for making any final decisions about the validity of metrics. In addition, we argue that cohesion and information-theoretic metrics are problematic if they are based on mathematical graphs which do not consider program semantics. We conclude that we should not adopt metrics from other disciplines if we cannot validate them properly. We propose the use of the representation condition as a means to demonstrate metrics that are not valid. We also believe that design metrics must make sense to software designers or, even if they are valid, they will not be used.

Research and Implementation of Program Code Similarity Measurement

Abstract: Aiming at the problem of program code similarity measurement,a combined method of attribute counting and structure metrics is proposedAttribute counting produces Halstead length,Halstead vocabulary and Halstead volume which constitute feature vector by counting the operator and operand of program source code,and attribute similarity can be calculated by using the cosine of vector included angleThe longest common subsequence algorithm is used to obtain structure similarityThe similar degree between two programs can be measured with the two similaritiesExperimental results show the method can effectively detect similar programs of the students’homework

Design-level metrics estimation based on code metrics

Abstract: Fault detection based on mining code and design metrics has been an active research area for many years. Basically "module"-based metrics for source code and design level are calculated or obtained and data mining is used to build predictor models. However, in many projects due to organizational or software process models, design level metrics are not available and/or accurate. It has been shown that performance of these classifiers or predictors decline if only source code features are used for training them. Based on best of our know knowledge no set of rule to estimate design level metrics based on code level metrics has been presented since it is believed that design level metrics have additional information and cannot be estimated without access to design artifacts. In this study we present a fuzzy modeling system to find and present these relationships for projects presented in NASA Metrics Data Repository (MDP) datasets. Interestingly, we could find a set of empirical rules that govern all the projects regardless of size, programming language and software development methodology. Comparison of fault detectors built based on estimated design metrics with actual design metrics on various projects showed a very small difference in accuracy of classifiers and validated our hypothesis that estimation of design metrics based on source code attributes can become a practical exercise.

The software developers' view on product metrics - A survey-based experiment

Abstract: Object-oriented metrics are becoming evermore popular and they are used in many different areas of software development. Many researchers have showed in practice that object-oriented metrics can be efficiently used for quality assurance. For example, a lot of experimental results confirm that some of the object-oriented metrics (like coupling, size, and complexity) are able to predict the fault-proneness of classes. Quality assurance experts usually accept that actively applying metrics can help their work. On the other hand, developers tend not to use metrics because they do not know about them, or if they do know about them, they do not really know how to use them. Hence we devised a Survey to ask developers with different levels of experience about the use of metrics. Our hypothesis was that developers with different levels of experience might have significantly different views about the usefulness of metrics. In the Survey four metrics (size, complexity, coupling, and code duplication) were examined. The Survey asked questions about the participants’ experience and skills, then it asked questions about how the participants would probably use these metrics for software testing or program comprehension, and at the end the relative importance of the metrics was assessed. The main result of the Survey is a list which contains those cases where the views about the metrics from developers having different experience significantly differ. We think that getting to know the developers’ views better can help us to create better quality models based on object-oriented metrics.

Software metric analysis methods for product development / maintenance projects

Abstract: This paper presents an overview of the collection, analysis, and reporting of software metrics. Only the progress, effort and trouble report metrics are required for the project. However, the student should be familiar with all the metrics described below. Software metrics are numerical data related to software development. Metrics strongly support software project management activities. They relate to the four functions of management as follows: 1. Planning - Metrics serve as a basis of cost estimating, training planning, resource planning, scheduling, and budgeting. 2. Organizing - Size and schedule metrics influence a project's organization. 3. Controlling - Metrics are used to status and track software development activities for compliance to plans. 4. Improving - Metrics are used as a tool for process improvement and to identify where improvement efforts should be concentrated and measure the effects of process improvement efforts. A metric quantifies a characteristic of a process or product. Metrics can be directly observable quantities or can be derived from one or more directly observable quantities. Examples of raw metrics include the number of source lines of code, number of documentation pages, number of staff-hours, number of tests, number of requirements,