Source code quality plays a key role in software quality mainly due to its impact on software maintainability. Software engineers have been using source code metrics to support them to assess source code quality. Source code metrics quantify different source code characteristics. However, source code metric analysis still involves subjectivity. For instance, it is not trivial to decide whether a metric value is high or low. To reduce the eventual subjectivity of source code metrics analysis, several researchers are using Machine Learning algorithms. Therefore, in this paper, we designed a Fuzzy-based approach to extract characteristics and patterns present in source code versioning repositories in order to: i) assist the specialist in the interpretation of releases, especially when working with large volumes of source code; ii) from the release interpretation, specialists can improve the quality of the source code; and iii) monitor the evolution of the software as new releases are submitted to the repositories. We evaluated the proposed approach with the Linux Test Project repository, emphasizing the interpretability of large source code versioning repositories.

Context: System modeling usually precedes coding activities during software development. Addressing model smells in the upfront can avoid their propagation to the source code. Technical debt (TD) affects several software development phases, including design, but little is still known about it at the modeling level. Goal: Investigate whether applying refactoring procedures in UML class diagrams improves the quality of the automatically generated code in terms of TD (code debt) reduction. Method: We perform three replications of an empirical study following the same protocol used in the original study, but with variations on the: (1) round- trip engineering tool, (2) code issue identification tool, and (3) analyzed class diagram. Each study considered two sets of refactoring tasks. The first applied successive model refactoring sessions in a class diagram and analyzed their resulting automatically generated code. The second applied successive code refactoring sessions and analyzed their resulting automatically generated model. Results: There is a weak relationship between the analyzed model smells and code issues. Round-trip engineering tools influence the presence of code issues. Lastly, code issues identification tools mostly consider code formatting problems, in detriment of design issues smells. Conclusion: Results confirm the findings of the original study and motivate further investigation on the correspondence between model smells and code issues to prevent code debt at the model level.

Background: Conditional compilation is often used to implement variability in configurable systems. This technique relies on #ifdefs to delimit feature code. Previous studies have shown that #ifdefs may hinder code comprehensibility. However, they did not explicitly took feature dependencies into account. Feature dependency occurs when different features refer to the same program element, such as a variable. Comprehensibility may be even more affected in the presence of feature dependency, as the developer must reason about different scenarios affecting the same variable. Aim: Our goal is to understand how feature dependency affects the comprehensibility of configurable system source code. Method: We carried out an experiment in which 30 developers debugged programs with different types of feature dependency. We recorded the time each of them had spent to find a bug. Also, we used an eye-tracking device to record developers' gaze movements while they debugged programs. Results: Debugging programs with global and interprocedural dependency required more time and higher visual effort. Conclusion: Our study showed that #ifdefs affect comprehensibility in different degrees depending on the type of feature dependency. Therefore, when possible, developers should take more care when dealing with code with global and interprocedural dependencies.

Background. Source code analysis techniques usually rely on metric-based assessment. However, most of these techniques have low accuracy. One possible reason is because metric thresholds are extracted from classes driven by distinct design decisions. Previous studies have already shown that classes implemented according to some coarse-grained design decisions, such as programming languages, have different distribution of metric values. Therefore, these design decisions should be taken into account when using benchmarks for metric-based source code analysis. Goal. Our goal is to investigate whether other fine-grained design decisions also influence over distribution of software metrics. Method. We conduct an empirical study to evaluate the distributions of four metrics applied over fifteen real-world systems based on three different domains. Initially, we evaluated the influence of the class design role on the distributions of measures. For this purpose, we have defined an automatic approach to identify the design role played by each class. Then, we looked for other fine-grained design decisions that could have influenced the measures. Results. Our findings show that distribution of metrics are sensitive to the following design decisions: (i) design role of the class (ii) used libraries, (iii) coding style, (iv) exception handling, and (v) logging and debugging code mechanisms. Conclusion. The distribution of software metrics are sensitive to fine-grained design decisions and we should consider taking them into account when building benchmarks for metric-based source code analysis.

Although it is assumed that the implementation of design by contract is better modularized by means of aspect-oriented (AO) programming, there is no empirical evidence on the effectiveness of AO for modularizing non-trivial design by contract code in realistic development scenarios. This paper reports a quantitative and qualitative case study that evolves a real-life application to assess various facets of the adequacy of aspects for modularizing the design by contract concern. Our evaluation focused upon a number of system changes that are typically performed during software maintenance tasks. The study was driven by an analysis of fundamental modularity attributes, such as separation of concerns, coupling, conciseness, and change propagation. We have found that AO techniques improved separation of concerns and the design stability between the design by contract code and base application code throughout the development scenarios. However, contradicting the general intuition, the AO versions of the system did not present significant gains regarding four classical size metrics we employed.

SUMMARY When reflecting upon driving system requirements such as security and availability, software architects often face decisions that have a broadly scoped impact on the software architecture. These decisions are the core of the architecting process because they typically have implications intertwined in a multitude of architectural elements and across multiple views. Without a modular representation and management of those crucial choices, architects cannot properly communicate, assess and reason about their crosscutting effects. The result is a number of architectural breakdowns, such as misinformed architectural evaluation, time‐consuming trade‐off analysis and unmanageable traceability. This paper presents an architectural documentation approach in which aspects are exploited as a natural way to capture widely‐scoped design decisions in a modular fashion. The approach consists of a simple high‐level notation to describe crosscutting decisions, and a supplementary language that allows architects to formally define how such architectural decisions affect the final architectural decomposition according to different views. On the basis of two case studies, we have systematically assessed to what extent our approach: (i) supports the description of heterogeneous forms of crosscutting architecture decisions, (ii) improves the support for architecture modularity analysis, and (iii) enhances upstream and downstream traceability of crosscutting architectural decisions. Copyright © 2012 John Wiley & Sons, Ltd.

To achieve large-scale reuse and accelerate time-to-market, integration of multiple software product lines (SPLs) is becoming a trend. The integration of independently-developed SPLs enables the derivation of new products on demand in a particular domain. The basic goal is to foster the reuse of previously-implemented features across a family of independently-developed SPLs. The programming technique employed in this context should promote the reuse of feature code across the SPLs with minimum change effort. Otherwise, the stability of the target SPLs would be compromised. This paper presents an exploratory study on the stepwise integration of three product lines from the board game domain. We investigate how the programming mechanisms supported by aspect-oriented and feature-oriented programming impacted the reuse and stability of those product lines. In particular, we also analyse and compare how the use of these mechanisms made possible to reach a better tradeoff of reuse and stability of the SPL designs.

Cohesion has been avidly recognized as a key property of software modularity. Ideally, a software module is considered to be cohesive if it represents an abstraction of a single concern of the software. Modules with several concerns may be harder to understand because developers must mentally separate the source code related to each concern. Also, modules implementing several concerns are more likely to undergo changes as much as distinct development tasks may target its different concerns. The most well-known cohesion metrics are defined in terms of the syntactical structure of a module, and as a consequence fail to capture the amount of concerns realized by the module. In this context, we investigated the potential of a new metric, called Lack of Concern-based Cohesion. This metric explicitly counts the number of concerns realized by each module. We compared this metric with other five structural cohesion metrics by applying them over six open source software systems. We studied how those metrics are associated with module changes by mining over 16,000 repository revisions. Our results pointed out that the concern-based metric captured a cohesion dimension that is not reflected by structural metrics, and, as a consequence, adds to the association of cohesion and change-proneness.

It is often claimed that inaccurate modularisation of crosscutting concerns hinders program comprehension and, as a consequence, leads to harmful software instabilities. However, recent studies have pointed out that crosscutting concerns are not always harmful to design stability. Hence, software maintainers would benefit from well documented patterns of crosscutting concerns and a better understanding about their actual impact on design stability. This paper presents a catalogue of crosscutting concern patterns recurrently observed in software systems. These patterns are described and classified based on an intuitive vocabulary that facilitates their recognition by software engineers. We analysed instances of the crosscutting patterns in object-oriented and aspect-oriented versions of three evolving programs. The outcomes of our exploratory evaluation indicated that: (i) a certain category of crosscutting patterns seems to be good indicator of harmful instabilities, and (ii) aspect-oriented solutions were unable to modularise concerns matching some crosscutting patterns.

Software product lines (SPLs) enable modular, large-scale reuse through a software architecture addressing multiple core and varying features. To reap the benefits of SPLs, their designs need to be stable. Design stability encompasses the sustenance of the product line’s modularity properties in the presence of changes to both the core and varying features. It is usually assumed that aspect-oriented programming promotes better modularity and changeability of product lines. However, there is no empirical evidence on its efficacy to prolong design stability of product lines in realistic development scenarios. This paper reports a quantitative study that evolves two SPLs to assess various facets of design stability of aspect-oriented implementations. Our investigation focused upon a multi-perspective analysis of the evolving product lines in terms of modularity, change propagation, and feature interaction.

One of the main promises of aspect-oriented programming (AOP) is to promote improved modularization of crosscutting concerns, thereby enhancing the software stability in the presence of changes. This paper presents a quantitative study that assesses the positive and negative effects of AOP on typical maintenance activities of a Web information system. The study consists of a systematic comparison between the object-oriented and the aspect-oriented versions of the same application in order to assess to what extent each solution provides maintainable software decompositions. Our analysis was driven by fundamental modularity attributes, such as coupling, cohesion, conciseness, and separation of concerns. We have found that the aspect-oriented design has exhibited superior stability and reusability through the changes, as it has resulted in fewer lines of code, improved separation of concerns, weaker coupling, and lower intra-component complexity