In this paper, we present a collection of aspect-oriented refactorings covering both the extraction of aspects from objectoriented legacy code and the subsequent tidying up of the resulting aspects. In some cases, this tidying up entails the replacement of the original implementation with a different, centralized design, made possible by modularization. The collection of refactorings includes the extraction of common code in various aspects into abstract superaspects. We review the traditional object-oriented code smells in the light of aspectorientation and propose some new smells for the detection of crosscutting concerns. In addition, we propose a new code smell that is specific to aspects.

Abstract. In this paper, we contribute to the characterisation of a programming style specific to aspect-oriented programming. For this purpose, we present a collection of refactorings for aspect-oriented source code, comprising refactorings to enable extraction to aspects of crosscutting concerns from objectoriented legacy code, the subsequent tidying up of the extracted aspects and factoring out of common code from similar aspects to superaspects. The second group of refactorings is documented in detail. In addition, we propose some new aspect-oriented code smells, including one smell that is specific to aspect modules. We also propose a reinterpretation of some of the traditional objectoriented code smells in the light of aspect-orientation, to detect the presence of crosscutting concerns.

In this paper, we present a collection of well-known high-level concurrency patterns and mechanisms, coded in AspectJ. We discuss benefits of these implementations relative to plain Java implementations of the same concerns. We detect benefits from using AspectJ in all the cases presented, in the form of higher modularity, reuse, understandability and unpluggability. For most of the implementations, two alternatives can be used: one based on traditional pointcut interfaces and one based on annotations.

This paper describes a refactoring process transforming a Java code base into an AspectJ equivalent. The process illustrates 17 aspect-oriented refactorings covering extraction of implementation elements to aspects, internal reorganization of extracted aspects, and extraction of commonalities to superaspects.

Matrix and data manipulation programming languages are an essential tool for data analysts. However, these languages are often unstructured and lack modularity mechanisms. This article presents a knowledge discovery approach for studying manifestations of the lack of modularity support in that sort of languages. The study is focused on Matlab, as a well‐established representative of those languages. We present a technique for the automatic detection and quantification of concerns in Matlab and their exploration in a code base. The Ubiquitous Self Organizing Map (UbiSOM) is used to perform exploratory data analysis over concerns detected in a, possibly changing, repository of Matlab files. The UbiSOM is quite effective in detecting patterns of co‐occurrence of multiple concerns. To illustrate the technique, a repository comprising over 35,000 Matlab files is analysed. The results show that the use of Token Density metrics in conjunction with UbiSOM enables the detection of patterns of co‐occurrence of multiple concerns in m‐files.

Context: Code smells are associated to poor design and programming style, which often degrades code quality and hampers code comprehensibility and maintainability. Goal: identify published studies that provide evidence of the influence of code smells on the occurrence of software bugs. Method: We conducted a Systematic Literature Review (SLR) to reach the stated goal. Results: The SLR selected studies from July 2007 to September 2017, which analyzed the source code of open source software projects and several code smells. Based on evidence of 16 studies covered in this SLR, we conclude that 24 code smells are more influential in the occurrence of bugs relative to the remaining smells analyzed. In contrast, three studies reported that at least 6 code smells are less influential in such occurrences. Evidence from the selected studies also point out tools, techniques, and procedures that should be applied to analyze the influence of the smells. Conclusions: To the best of our knowledge, this is the first SLR to target this goal. This study provides an up-to-date and structured understanding of the influence of code smells on the occurrence of software bugs based on findings systematically collected from a list of relevant references in the latest decade.

No abstract

No abstract