From a Domain Analysis to the Specification and Detection of Code and Design Smells

Code and design smells are recurring design problems in software systems that must be identified to avoid their possible negative consequences\ud on development and maintenance. Consequently, several smell detection\ud approaches and tools have been proposed in the literature. However,\ud so far, they allow the detection of predefined smells but the detection\ud of new smells or smells adapted to the context of the analysed systems\ud is possible only by implementing new detection algorithms manually.\ud Moreover, previous approaches do not explain the transition from\ud specifications of smells to their detection. Finally, the validation\ud of the existing approaches and tools has been limited on few proprietary\ud systems and on a reduced number of smells. In this paper, we introduce\ud an approach to automate the generation of detection algorithms from\ud specifications written using a domain-specific language. This language\ud is defined from a thorough domain analysis. It allows the specification\ud of smells using high-level domain-related abstractions. It allows\ud the adaptation of the specifications of smells to the context of\ud the analysed systems.We specify 10 smells, generate automatically\ud their detection algorithms using templates, and validate the algorithms\ud in terms of precision and recall on Xerces v2.7.0 and GanttProject\ud v1.10.2, two open-source object-oriented systems.We also compare\ud the detection results with those of a previous approach, iPlasma

A Domain Analysis to Specify Design Defects and Generate Detection Algorithms

Quality experts often need to identify in software systems design defects, which are recurring design problems, that hinder development\ud and maintenance. Consequently, several defect detection approaches\ud and tools have been proposed in the literature. However, we are not\ud aware of any approach that defines and reifies the process of generating\ud detection algorithms from the existing textual descriptions of defects.\ud In this paper, we introduce an approach to automate the generation\ud of detection algorithms from specifications written using a domain-specific\ud language. The domain-specific is defined from a thorough domain analysis.\ud We specify several design defects, generate automatically detection\ud algorithms using templates, and validate the generated detection\ud algorithms in terms of precision and recall on Xerces v2.7.0, an\ud open-source object-oriented system

30 Years of Software Refactoring Research:A Systematic Literature Review

Due to the growing complexity of software systems, there has been a dramatic increase and industry demand for tools and techniques on software refactoring in the last ten years, defined traditionally as a set of program transformations intended to improve the system design while preserving the behavior. Refactoring studies are expanded beyond code-level restructuring to be applied at different levels (architecture, model, requirements, etc.), adopted in many domains beyond the object-oriented paradigm (cloud computing, mobile, web, etc.), used in industrial settings and considered objectives beyond improving the design to include other non-functional requirements (e.g., improve performance, security, etc.). Thus, challenges to be addressed by refactoring work are, nowadays, beyond code transformation to include, but not limited to, scheduling the opportune time to carry refactoring, recommendations of specific refactoring activities, detection of refactoring opportunities, and testing the correctness of applied refactorings. Therefore, the refactoring research efforts are fragmented over several research communities, various domains, and objectives. To structure the field and existing research results, this paper provides a systematic literature review and analyzes the results of 3183 research papers on refactoring covering the last three decades to offer the most scalable and comprehensive literature review of existing refactoring research studies. Based on this survey, we created a taxonomy to classify the existing research, identified research trends, and highlighted gaps in the literature and avenues for further research.Comment: 23 page

30 Years of Software Refactoring Research: A Systematic Literature Review

Peer Reviewedhttps://deepblue.lib.umich.edu/bitstream/2027.42/155872/4/30YRefactoring.pd

Why did you clone these identifiers? Using Grounded Theory to understand Identifier Clones

Developers spend most of their time comprehending source code, with some studies estimating this activity takes between 58% to 70% of a developer’s time. To improve the readability of source code, and therefore the productivity of developers, it is important to understand what aspects of static code analysis and syntactic code structure hinder the understandability of code. Identifiers are a main source of code comprehension due to their large volume and their role as implicit documentation of a developer’s intent when writing code. Despite the critical role that identifiers play during program comprehension, there are no regulated naming standards for developers to follow when picking identifier names. Our research supports previous work aimed at understanding what makes a good identifier name, and practices to follow when picking names by exploring a phenomenon that occurs during identifier naming: identifier clones. Identifier clones are two or more identifiers that are declared using the same name. This is an important yet unexplored phenomenon in identifier naming where developers intentionally give the same name to two or more identifiers in separate parts of a system. We must study identifier clones to understand it’s impact on program comprehension and to better understand the nature of identifier naming. To accomplish this, we conducted an empirical study on identifier clones detected in open-source software engineered systems and propose a taxonomy of identifier clones containing categories that can explain why they are introduced into systems and whether they represent naming antipatterns

“Refactoring” Refactoring

Code refactoring’s primary impetus is to control technical debt, a metaphor for the cost in software development due to the extraneous human effort needed to resolve confusing, obfuscatory, or hastily-crafted program code. While these issues are often described as causing “bad smells,” not all bad smells emanate from the code itself. Some (often the most pungent and costly) originate in the formation, or expressions, of the antecedent intensions the software proposes to satisfy. Paying down such technical debt requires more than grammatical manipulations of the code. Rather, refactoring in this case must attend to a more inclusive perspective; particularly how stakeholders perceive the artifact; and their conception of quality – their appreciative system. First, this paper explores refactoring as an evolutionary design activity. Second, we generalize, or “refactor,” the concept of code refactoring, beyond changes to code structure, to improving design quality by incorporating the stakeholders’ experience of the artifact as it relates to their intensions. Third, we integrate this refactored refactoring as the organizing principle of design as a reflective practice. The objective is to improve the clarity, understandability, maintainability, and extensibility manifest in the stakeholder intensions, in the artifact, and in their interrelationship

Did You Remember to Test Your Tokens?

Authentication is a critical security feature for confirming the identity of a system's users, typically implemented with help from frameworks like Spring Security. It is a complex feature which should be robustly tested at all stages of development. Unit testing is an effective technique for fine-grained verification of feature behaviors that is not widely-used to test authentication. Part of the problem is that resources to help developers unit test security features are limited. Most security testing guides recommend test cases in a "black box" or penetration testing perspective. These resources are not easily applicable to developers writing new unit tests, or who want a security-focused perspective on coverage. In this paper, we address these issues by applying a grounded theory-based approach to identify common (unit) test cases for token authentication through analysis of 481 JUnit tests exercising Spring Security-based authentication implementations from 53 open source Java projects. The outcome of this study is a developer-friendly unit testing guide organized as a catalog of 53 test cases for token authentication, representing unique combinations of 17 scenarios, 40 conditions, and 30 expected outcomes learned from the data set in our analysis. We supplement the test guide with common test smells to avoid. To verify the accuracy and usefulness of our testing guide, we sought feedback from selected developers, some of whom authored unit tests in our dataset.Comment: In 17th International Conference on Mining Software Repositories (MSR) 2020, Technical Track, Virtual. 11 page