Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609692
T. Gergely, Árpád Beszédes, T. Gyimóthy, Milan Imre Gyalai
In risk-based testing, compromises are often made to release a system in spite of knowing that it has outstanding defects. In an industrial setting, time and cost are often the “exit criteria” and - unfortunately - not the technical aspects like coverage or defect ratio. In such situations, the stakeholders accept that the remaining defects will be found after release, so sufficient resources are allocated to the “stabilization” phases following the release. It is hard for many organizations to see that such an approach is significantly costlier than trying to locate the defects earlier. We performed an empirical investigation of this for one of our industrial partners (a financial company). In this project, significant perfective maintenance was performed on the large information system. Based on changes made to the system, we carried out procedure level code coverage measurements with code level change impact analysis, and a similarity-based comparison of test cases in order to quantitatively check the completeness and redundancy of the tests performed. In addition, we logged and compared the number of defects found during testing and live operation. The data obtained were surprising for both the developers and the customer as well, leading to a major reorganization of their development, testing, and operation processes. After the reorganization, a significant improvement in these indicators for testing efficiency was observed.
{"title":"Effect of test completeness and redundancy measurement on post release failures — An industrial experience report","authors":"T. Gergely, Árpád Beszédes, T. Gyimóthy, Milan Imre Gyalai","doi":"10.1109/ICSM.2010.5609692","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609692","url":null,"abstract":"In risk-based testing, compromises are often made to release a system in spite of knowing that it has outstanding defects. In an industrial setting, time and cost are often the “exit criteria” and - unfortunately - not the technical aspects like coverage or defect ratio. In such situations, the stakeholders accept that the remaining defects will be found after release, so sufficient resources are allocated to the “stabilization” phases following the release. It is hard for many organizations to see that such an approach is significantly costlier than trying to locate the defects earlier. We performed an empirical investigation of this for one of our industrial partners (a financial company). In this project, significant perfective maintenance was performed on the large information system. Based on changes made to the system, we carried out procedure level code coverage measurements with code level change impact analysis, and a similarity-based comparison of test cases in order to quantitatively check the completeness and redundancy of the tests performed. In addition, we logged and compared the number of defects found during testing and live operation. The data obtained were surprising for both the developers and the customer as well, leading to a major reorganization of their development, testing, and operation processes. After the reorganization, a significant improvement in these indicators for testing efficiency was observed.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115012738","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609739
G. Bavota, R. Oliveto, A. D. Lucia, G. Antoniol, Yann-Gaël Guéhéneuc
In software engineering, developers must often find solutions to problems balancing competing goals, e.g., quality versus cost, time to market versus resources, or cohesion versus coupling. Finding a suitable balance between contrasting goals is often complex and recommendation systems are useful to support developers and managers in performing such a complex task. We believe that contrasting goals can be often dealt with game theory techniques. Indeed, game theory is successfully used in other fields, especially in economics, to mathematically propose solutions to strategic situation, in which an individual's success in making choices depends on the choices of others. To demonstrate the applicability of game theory to software engineering and to understand its pros and cons, we propose an approach based on game theory that recommend extract-class refactoring opportunities. A preliminary evaluation inspired by mutation testing demonstrates the applicability and the benefits of the proposed approach.
{"title":"Playing with refactoring: Identifying extract class opportunities through game theory","authors":"G. Bavota, R. Oliveto, A. D. Lucia, G. Antoniol, Yann-Gaël Guéhéneuc","doi":"10.1109/ICSM.2010.5609739","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609739","url":null,"abstract":"In software engineering, developers must often find solutions to problems balancing competing goals, e.g., quality versus cost, time to market versus resources, or cohesion versus coupling. Finding a suitable balance between contrasting goals is often complex and recommendation systems are useful to support developers and managers in performing such a complex task. We believe that contrasting goals can be often dealt with game theory techniques. Indeed, game theory is successfully used in other fields, especially in economics, to mathematically propose solutions to strategic situation, in which an individual's success in making choices depends on the choices of others. To demonstrate the applicability of game theory to software engineering and to understand its pros and cons, we propose an approach based on game theory that recommend extract-class refactoring opportunities. A preliminary evaluation inspired by mutation testing demonstrates the applicability and the benefits of the proposed approach.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123693587","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609735
C. Bezemer, A. Zaidman, Bart Platzbeecker, Toine Hurkmans, Aad 't Hart
Multi-tenancy is a relatively new software architecture principle in the realm of the Software as a Service (SaaS) business model. It allows to make full use of the economy of scale, as multiple customers - “tenants” - share the same application and database instance. All the while, the tenants enjoy a highly configurable application, making it appear that the application is deployed on a dedicated server. The major benefits of multi-tenancy are increased utilization of hardware resources and improved ease of maintenance, resulting in lower overall application costs, making the technology attractive for service providers targeting small and medium enterprises (SME). Therefore, migrating existing single-tenant to multi-tenant applications can be interesting for SaaS software companies. In this paper we report on our experiences with reengineering an existing industrial, single-tenant software system into a multitenant one using a lightweight reengineering approach.
{"title":"Enabling multi-tenancy: An industrial experience report","authors":"C. Bezemer, A. Zaidman, Bart Platzbeecker, Toine Hurkmans, Aad 't Hart","doi":"10.1109/ICSM.2010.5609735","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609735","url":null,"abstract":"Multi-tenancy is a relatively new software architecture principle in the realm of the Software as a Service (SaaS) business model. It allows to make full use of the economy of scale, as multiple customers - “tenants” - share the same application and database instance. All the while, the tenants enjoy a highly configurable application, making it appear that the application is deployed on a dedicated server. The major benefits of multi-tenancy are increased utilization of hardware resources and improved ease of maintenance, resulting in lower overall application costs, making the technology attractive for service providers targeting small and medium enterprises (SME). Therefore, migrating existing single-tenant to multi-tenant applications can be interesting for SaaS software companies. In this paper we report on our experiences with reengineering an existing industrial, single-tenant software system into a multitenant one using a lightweight reengineering approach.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115383114","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609679
Klaus Haller
Information systems are applications incorporating a database for storing and processing data. Upgrading information systems requires updating the application logic, modifying the database schema, and adopting the data accordingly. Previous research focuses either on schema evolution or on application logic updates. In this paper, we take a holistic approach by addressing the combination. First, we elaborate the three main upgrade patterns: install & copy, rejuvenation/delta only, and rejuvenation/verified. Second, we introduce our upgrade correctness concept. It is a formal correctness criterion for deciding whether an upgrade succeeded. Third, we discuss implementation patterns. Our insights base on various upgrade projects from stand-alone applications to multi-tenant systems having affected more than one hundred banks.
{"title":"On the implementation and correctness of information system upgrades","authors":"Klaus Haller","doi":"10.1109/ICSM.2010.5609679","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609679","url":null,"abstract":"Information systems are applications incorporating a database for storing and processing data. Upgrading information systems requires updating the application logic, modifying the database schema, and adopting the data accordingly. Previous research focuses either on schema evolution or on application logic updates. In this paper, we take a holistic approach by addressing the combination. First, we elaborate the three main upgrade patterns: install & copy, rejuvenation/delta only, and rejuvenation/verified. Second, we introduce our upgrade correctness concept. It is a formal correctness criterion for deciding whether an upgrade succeeded. Third, we discuss implementation patterns. Our insights base on various upgrade projects from stand-alone applications to multi-tenant systems having affected more than one hundred banks.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"75 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122887108","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609553
Seyed Mehdi Nasehi, F. Maurer
This study aims to find out if API unit tests can provide good usage examples, and if so, what prevents developers from finding and using those examples. The results of an experiment we performed with two groups of developers showed that unit tests can be very helpful, especially when the task is complicated and involves multiple classes and methods. Well-written tests proved to be a good source of examples, but finding the relevant examples using the standard tools might be very difficult. We propose to supplement the standard API documentation with relevant examples taken from the unit tests. To further improve the learnability of the API, presentation of the documentation and examples has to be tailored in a way that separates or hides advanced usage scenarios from the commonly used ones.
{"title":"Unit tests as API usage examples","authors":"Seyed Mehdi Nasehi, F. Maurer","doi":"10.1109/ICSM.2010.5609553","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609553","url":null,"abstract":"This study aims to find out if API unit tests can provide good usage examples, and if so, what prevents developers from finding and using those examples. The results of an experiment we performed with two groups of developers showed that unit tests can be very helpful, especially when the task is complicated and involves multiple classes and methods. Well-written tests proved to be a good source of examples, but finding the relevant examples using the standard tools might be very difficult. We propose to supplement the standard API documentation with relevant examples taken from the unit tests. To further improve the learnability of the API, presentation of the documentation and examples has to be tailored in a way that separates or hides advanced usage scenarios from the commonly used ones.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"55 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129569271","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609533
I. Keivanloo, Laleh Roostapour, Philipp Schügerl, J. Rilling
Available code search engines provide typically coarse-grained lexical search. To address this limitation we present SE-CodeSearch, a Semantic Web-based approach for Internet-scale source code search. It uses an ontological representation of source code facts and analysis knowledge to complete missing information using inference engine. This approach allows us to reason and search across project boundaries containing often incomplete code fragments extracted in a one-pass and no-order manner. The infrastructure provides a scalable approach to process and query across large code bases mined from software repositories and code fragments found online. We have implemented our SE-CodeSearch as part of SE-Advisor framework to demonstrate the scalability and applicability of our Internet-scale code search in a software maintenance context.
{"title":"SE-CodeSearch: A scalable Semantic Web-based source code search infrastructure","authors":"I. Keivanloo, Laleh Roostapour, Philipp Schügerl, J. Rilling","doi":"10.1109/ICSM.2010.5609533","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609533","url":null,"abstract":"Available code search engines provide typically coarse-grained lexical search. To address this limitation we present SE-CodeSearch, a Semantic Web-based approach for Internet-scale source code search. It uses an ontological representation of source code facts and analysis knowledge to complete missing information using inference engine. This approach allows us to reason and search across project boundaries containing often incomplete code fragments extracted in a one-pass and no-order manner. The infrastructure provides a scalable approach to process and query across large code bases mined from software repositories and code fragments found online. We have implemented our SE-CodeSearch as part of SE-Advisor framework to demonstrate the scalability and applicability of our Internet-scale code search in a software maintenance context.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129584421","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609670
Abram Hindle, Michael W. Godfrey, R. Holt
The development process for a given software system is a combination of an idealized, prescribed model and a messy set of ad hoc practices. To some degree, process compliance can be enforced by supporting tools that require various steps be followed in order; however, this approach is often perceived as heavyweight and inflexible by developers, who generally prefer that tools support their desired work habits rather than limit their choices. An alternative approach to monitoring process compliance is to instrument the various tools and repositories that developers use — such as version control systems, bug-trackers, and mailing-list archives — and to build models of the de facto development process through observation, analysis, and inference. In this paper, we present a technique for recovering a project's software development processes from a variety of existing artifacts. We first apply unsupervised and supervised techniques — including word-bags, topic analysis, summary statistics, and Bayesian classifiers — to annotate software artifacts by related topics, maintenance types, and non-functional requirements. We map the analysis results onto a time-line based view of the Unified Process development model, which we call Recovered Unified Process Views. We demonstrate our approach for extracting these process views on two case studies: FreeBSD and SQLite.
{"title":"Software process recovery using Recovered Unified Process Views","authors":"Abram Hindle, Michael W. Godfrey, R. Holt","doi":"10.1109/ICSM.2010.5609670","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609670","url":null,"abstract":"The development process for a given software system is a combination of an idealized, prescribed model and a messy set of ad hoc practices. To some degree, process compliance can be enforced by supporting tools that require various steps be followed in order; however, this approach is often perceived as heavyweight and inflexible by developers, who generally prefer that tools support their desired work habits rather than limit their choices. An alternative approach to monitoring process compliance is to instrument the various tools and repositories that developers use — such as version control systems, bug-trackers, and mailing-list archives — and to build models of the de facto development process through observation, analysis, and inference. In this paper, we present a technique for recovering a project's software development processes from a variety of existing artifacts. We first apply unsupervised and supervised techniques — including word-bags, topic analysis, summary statistics, and Bayesian classifiers — to annotate software artifacts by related topics, maintenance types, and non-functional requirements. We map the analysis results onto a time-line based view of the Unified Process development model, which we call Recovered Unified Process Views. We demonstrate our approach for extracting these process views on two case studies: FreeBSD and SQLite.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129728284","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609736
P. Bhattacharya, Iulian Neamtiu
Software bugs are inevitable and bug fixing is a difficult, expensive, and lengthy process. One of the primary reasons why bug fixing takes so long is the difficulty of accurately assigning a bug to the most competent developer for that bug kind or bug class. Assigning a bug to a potential developer, also known as bug triaging, is a labor-intensive, time-consuming and fault-prone process if done manually. Moreover, bugs frequently get reassigned to multiple developers before they are resolved, a process known as bug tossing. Researchers have proposed automated techniques to facilitate bug triaging and reduce bug tossing using machine learning-based prediction and tossing graphs. While these techniques achieve good prediction accuracy for triaging and reduce tossing paths, they are vulnerable to several issues: outdated training sets, inactive developers, and imprecise, single-attribute tossing graphs. In this paper we improve triaging accuracy and reduce tossing path lengths by employing several techniques such as refined classification using additional attributes and intra-fold updates during training, a precise ranking function for recommending potential tossees in tossing graphs, and multi-feature tossing graphs. We validate our approach on two large software projects, Mozilla and Eclipse, covering 856,259 bug reports and 21 cumulative years of development. We demonstrate that our techniques can achieve up to 83.62% prediction accuracy in bug triaging. Moreover, we reduce tossing path lengths to 1.5–2 tosses for most bugs, which represents a reduction of up to 86.31% compared to original tossing paths. Our improvements have the potential to significantly reduce the bug fixing effort, especially in the context of sizable projects with large numbers of testers and developers.
{"title":"Fine-grained incremental learning and multi-feature tossing graphs to improve bug triaging","authors":"P. Bhattacharya, Iulian Neamtiu","doi":"10.1109/ICSM.2010.5609736","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609736","url":null,"abstract":"Software bugs are inevitable and bug fixing is a difficult, expensive, and lengthy process. One of the primary reasons why bug fixing takes so long is the difficulty of accurately assigning a bug to the most competent developer for that bug kind or bug class. Assigning a bug to a potential developer, also known as bug triaging, is a labor-intensive, time-consuming and fault-prone process if done manually. Moreover, bugs frequently get reassigned to multiple developers before they are resolved, a process known as bug tossing. Researchers have proposed automated techniques to facilitate bug triaging and reduce bug tossing using machine learning-based prediction and tossing graphs. While these techniques achieve good prediction accuracy for triaging and reduce tossing paths, they are vulnerable to several issues: outdated training sets, inactive developers, and imprecise, single-attribute tossing graphs. In this paper we improve triaging accuracy and reduce tossing path lengths by employing several techniques such as refined classification using additional attributes and intra-fold updates during training, a precise ranking function for recommending potential tossees in tossing graphs, and multi-feature tossing graphs. We validate our approach on two large software projects, Mozilla and Eclipse, covering 856,259 bug reports and 21 cumulative years of development. We demonstrate that our techniques can achieve up to 83.62% prediction accuracy in bug triaging. Moreover, we reduce tossing path lengths to 1.5–2 tosses for most bugs, which represents a reduction of up to 86.31% compared to original tossing paths. Our improvements have the potential to significantly reduce the bug fixing effort, especially in the context of sizable projects with large numbers of testers and developers.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"24 3","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"120867706","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609557
Hongyu Zhang, Bei Shi, Lu Zhang
Open source software facilitates software reuse as developers can learn from code in existing open source projects. However, license compliance is an important legal issue that should be taken into consideration during open source based software reuse. Ignorance or carelessness could result in huge financial losses. In this paper, we present LChecker, a tool we developed for automatic checking of license compliance. LChecker utilizes Google Code Search service to check whether a local file exists in an OSS project and whether the licenses are compatible. The initial experimental results show that our tool is effective in detecting license compliance problems1.
{"title":"Automatic checking of license compliance","authors":"Hongyu Zhang, Bei Shi, Lu Zhang","doi":"10.1109/ICSM.2010.5609557","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609557","url":null,"abstract":"Open source software facilitates software reuse as developers can learn from code in existing open source projects. However, license compliance is an important legal issue that should be taken into consideration during open source based software reuse. Ignorance or carelessness could result in huge financial losses. In this paper, we present LChecker, a tool we developed for automatic checking of license compliance. LChecker utilizes Google Code Search service to check whether a local file exists in an OSS project and whether the licenses are compatible. The initial experimental results show that our tool is effective in detecting license compliance problems1.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"234 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122481639","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}
Pub Date : 2010-09-12DOI: 10.1109/ICSM.2010.5609564
Steffen M. Olbrich, D. Cruzes, Dag I.K. Sjøberg
Code smells are particular patterns in object-oriented systems that are perceived to lead to difficulties in the maintenance of such systems. It is held that to improve maintainability, code smells should be eliminated by refactoring. It is claimed that classes that are involved in certain code smells are liable to be changed more frequently and have more defects than other classes in the code. We investigated the extent to which this claim is true for God Classes and Brain Classes, with and without normalizing the effects with respect to the class size. We analyzed historical data from 7 to 10 years of the development of three open-source software systems. The results show that God and Brain Classes were changed more frequently and contained more defects than other kinds of class. However, when we normalized the measured effects with respect to size, then God and Brain Classes were less subject to change and had fewer defects than other classes. Hence, under the assumption that God and Brain Classes contain on average as much functionality per line of code as other classes, the presence of God and Brain Classes is not necessarily harmful; in fact, such classes may be an efficient way of organizing code.
{"title":"Are all code smells harmful? A study of God Classes and Brain Classes in the evolution of three open source systems","authors":"Steffen M. Olbrich, D. Cruzes, Dag I.K. Sjøberg","doi":"10.1109/ICSM.2010.5609564","DOIUrl":"https://doi.org/10.1109/ICSM.2010.5609564","url":null,"abstract":"Code smells are particular patterns in object-oriented systems that are perceived to lead to difficulties in the maintenance of such systems. It is held that to improve maintainability, code smells should be eliminated by refactoring. It is claimed that classes that are involved in certain code smells are liable to be changed more frequently and have more defects than other classes in the code. We investigated the extent to which this claim is true for God Classes and Brain Classes, with and without normalizing the effects with respect to the class size. We analyzed historical data from 7 to 10 years of the development of three open-source software systems. The results show that God and Brain Classes were changed more frequently and contained more defects than other kinds of class. However, when we normalized the measured effects with respect to size, then God and Brain Classes were less subject to change and had fewer defects than other classes. Hence, under the assumption that God and Brain Classes contain on average as much functionality per line of code as other classes, the presence of God and Brain Classes is not necessarily harmful; in fact, such classes may be an efficient way of organizing code.","PeriodicalId":101801,"journal":{"name":"2010 IEEE International Conference on Software Maintenance","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131695186","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
扫码关注我们
求助内容：
应助结果提醒方式：