G. Concas, M. Marchesi, Alessandro Murgia, S. Pinna, R. Tonelli
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.
{"title":"Assessing traditional and new metrics for object-oriented systems","authors":"G. Concas, M. Marchesi, Alessandro Murgia, S. Pinna, R. Tonelli","doi":"10.1145/1809223.1809227","DOIUrl":"https://doi.org/10.1145/1809223.1809227","url":null,"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.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"23 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114496529","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Aspect Oriented Programming (AOP) introduces new types of coupling among the aspects and the components of the base system. Indeed, several and different new kinds of interactions among aspects and the other components can be introduced by the AOP constructs, allowing the alteration both of the structure, control and data flow of the components of the base system. These interactions can make higher the complexity of the overall system affecting its comprehension. In this paper we present a proposal for a metric model to classify the types of coupling among aspects and the components of the base system. The model can be used to define how each kind of coupling affects the complexity, and thus the comprehensibility, of the system.
{"title":"A metric model for aspects' coupling","authors":"M. Bernardi, G. D. Lucca","doi":"10.1145/1809223.1809232","DOIUrl":"https://doi.org/10.1145/1809223.1809232","url":null,"abstract":"Aspect Oriented Programming (AOP) introduces new types of coupling among the aspects and the components of the base system. Indeed, several and different new kinds of interactions among aspects and the other components can be introduced by the AOP constructs, allowing the alteration both of the structure, control and data flow of the components of the base system. These interactions can make higher the complexity of the overall system affecting its comprehension.\u0000 In this paper we present a proposal for a metric model to classify the types of coupling among aspects and the components of the base system. The model can be used to define how each kind of coupling affects the complexity, and thus the comprehensibility, of the system.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"34 1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123352830","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
There is increasing evidence that many object-oriented software size metrics are characterised by scale-free, powerlaw distributions. This means programs will have arbitrarily large components, and the size of the largest component will increase as programs' overall size increases. This directly contradicts a crucial assumption of object-oriented design --- that large programs can be build by combining many small components. In this paper, we present a preliminary study of this contradiction. We illustrate the distribution of several size metrics over a corpus of 100 Java systems, and then investigate the largest classes (according to five size and complexity metrics) from one of those systems. We find that, while some large classes may be explained by code-generation or design patterns, most large classes were examples of poor object-oriented design.
{"title":"Does size matter?: a preliminary investigation of the consequences of powerlaws in software","authors":"Joshua Lindsay, J. Noble, E. Tempero","doi":"10.1145/1809223.1809226","DOIUrl":"https://doi.org/10.1145/1809223.1809226","url":null,"abstract":"There is increasing evidence that many object-oriented software size metrics are characterised by scale-free, powerlaw distributions. This means programs will have arbitrarily large components, and the size of the largest component will increase as programs' overall size increases. This directly contradicts a crucial assumption of object-oriented design --- that large programs can be build by combining many small components.\u0000 In this paper, we present a preliminary study of this contradiction. We illustrate the distribution of several size metrics over a corpus of 100 Java systems, and then investigate the largest classes (according to five size and complexity metrics) from one of those systems. We find that, while some large classes may be explained by code-generation or design patterns, most large classes were examples of poor object-oriented design.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"8 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132369613","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Several widely used functionality measures, quality models, and other measures have been defined in Empirical Software Engineering by using weighted sums. The apparent simplicity in the definition and interpretation of weighted sums make them one of the preferred ways for defining new measures. However, they have a few inherent issues that may make their definition and use quite problematic. This paper provides a critical investigation about the intuition behind weighted sums and their theoretical and empirical validation pitfalls that may make them questionable when used in the definition of meaningful and practically useful measures. Using estimation models may alleviate at least some of the problems with weighted sums.
{"title":"On the use of weighted sums in the definition of measures","authors":"S. Morasca","doi":"10.1145/1809223.1809225","DOIUrl":"https://doi.org/10.1145/1809223.1809225","url":null,"abstract":"Several widely used functionality measures, quality models, and other measures have been defined in Empirical Software Engineering by using weighted sums. The apparent simplicity in the definition and interpretation of weighted sums make them one of the preferred ways for defining new measures. However, they have a few inherent issues that may make their definition and use quite problematic. This paper provides a critical investigation about the intuition behind weighted sums and their theoretical and empirical validation pitfalls that may make them questionable when used in the definition of meaningful and practically useful measures. Using estimation models may alleviate at least some of the problems with weighted sums.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129702479","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
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.
{"title":"Problems adopting metrics from other disciplines","authors":"B. Kitchenham, P. Brereton","doi":"10.1145/1809223.1809224","DOIUrl":"https://doi.org/10.1145/1809223.1809224","url":null,"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.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"24 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130173044","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
S. Counsell, R. Hierons, H. Hamza, S. Black, M. Durrand
Code smells reflect code decay and, as such, developers should seek to eradicate such smells through application of 'deodorant' in the form of one or more refactorings. However, a dearth of studies exploring code smells either theoretically or empirically suggests that there are reasons why smell eradication is neither being applied in anger, nor the subject of significant research. In this paper, we present three studies as supporting evidence for this claim. The first is an analysis of a set of five, open-source Java systems, the second an empirical study of a sub-system of a proprietary, C# web-based application and the third, a theoretical enumeration of smell-related refactorings. Key findings of the study were first, that developers seemed to avoid eradicating superficially 'simple' smells in favor of more 'obscure' ones; second, a wide range of conflicts and anomalies soon emerged when trying to identify smelly code. Finally, perceived effort to eradicate a smell may be a key factor. The study highlights the need for a clearer research strategy on the issue of code smells and all aspects of their identification and measurement.
{"title":"Is a strategy for code smell assessment long overdue?","authors":"S. Counsell, R. Hierons, H. Hamza, S. Black, M. Durrand","doi":"10.1145/1809223.1809228","DOIUrl":"https://doi.org/10.1145/1809223.1809228","url":null,"abstract":"Code smells reflect code decay and, as such, developers should seek to eradicate such smells through application of 'deodorant' in the form of one or more refactorings. However, a dearth of studies exploring code smells either theoretically or empirically suggests that there are reasons why smell eradication is neither being applied in anger, nor the subject of significant research. In this paper, we present three studies as supporting evidence for this claim. The first is an analysis of a set of five, open-source Java systems, the second an empirical study of a sub-system of a proprietary, C# web-based application and the third, a theoretical enumeration of smell-related refactorings. Key findings of the study were first, that developers seemed to avoid eradicating superficially 'simple' smells in favor of more 'obscure' ones; second, a wide range of conflicts and anomalies soon emerged when trying to identify smelly code. Finally, perceived effort to eradicate a smell may be a key factor. The study highlights the need for a clearer research strategy on the issue of code smells and all aspects of their identification and measurement.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"254 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133117771","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
SLOC (Source Lines-Of-Code) has been used extensively as a Code Size Measure, and as input to parametric software cost and effort estimation tools. SLOC is obtained by measuring FP (Function Points) on the requirements and multiplying by the SLOC/FP ratio from similar projects. This is done even though several studies show large variations in this ratio, due to weak correlation between FP and SLOC. However, in our previous experiments we have obtained strong correlation between CFP (COSMIC Function Points) and Bytes compiled code as Code Size Measure. The experiments were conducted in the automotive industry using software components developed by GM (General Motors). In this paper we explain the reasons behind the strong correlation. The main reasons are that we apply the COSMIC method on software components of similar type, with a 1-to-1 mapping to COSMIC. A strong correlation between the Functional Size Measure and the Code Size Measure is required to obtain accurate Code Size estimation results. To estimate the Code Size before the software is available, is important both for Cost/Effort estimation and design of electronic hardware.
{"title":"On the relationship between functional size and software code size","authors":"Kenneth Lind, Rogardt Heldal","doi":"10.1145/1809223.1809230","DOIUrl":"https://doi.org/10.1145/1809223.1809230","url":null,"abstract":"SLOC (Source Lines-Of-Code) has been used extensively as a Code Size Measure, and as input to parametric software cost and effort estimation tools. SLOC is obtained by measuring FP (Function Points) on the requirements and multiplying by the SLOC/FP ratio from similar projects. This is done even though several studies show large variations in this ratio, due to weak correlation between FP and SLOC. However, in our previous experiments we have obtained strong correlation between CFP (COSMIC Function Points) and Bytes compiled code as Code Size Measure. The experiments were conducted in the automotive industry using software components developed by GM (General Motors). In this paper we explain the reasons behind the strong correlation. The main reasons are that we apply the COSMIC method on software components of similar type, with a 1-to-1 mapping to COSMIC. A strong correlation between the Functional Size Measure and the Code Size Measure is required to obtain accurate Code Size estimation results. To estimate the Code Size before the software is available, is important both for Cost/Effort estimation and design of electronic hardware.","PeriodicalId":103819,"journal":{"name":"Workshop on Emerging Trends in Software Metrics","volume":"76 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122827370","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：