Architectural smells have been widely studied in the literature, and some approaches have been developed to assess their impact on software quality metrics. Yet, empirical evidence bridging architectural smells and software quality metrics, while jointly considering security and performance issues, is limited. In this study, we investigate whether refactoring architectural smells can improve software quality and address security and performance issues that frequently occur in open-source projects. To this end, we analyze software code across various application domains and automatically detect architectural smells, as well as security and performance issues, using a diverse set of tools. Then, we manually remove detected instances of architectural smells and check whether their removal affects quality, security, and performance metrics originally collected in the selected projects. Our results indicate that refactoring architectural smells improves software quality and performance indicators, but we observe a less significant impact on security vulnerabilities.

Refactoring code smells in a project can be easily done, while refactoring architectural smells is a more complex task that could have different effects on the overall quality of a project. Architectural smells represent one of the greatest sources of technical debt faced by practitioners and are symptoms of architectural degradation. In this paper, we investigate the impact of the refactoring of architectural smells on technical debt and other software quality metrics. We focus our attention on smells found in microservice projects and also explore whether the refactoring of these smells can support the identification of new microservices. We analyze microservice projects due to the increasing interest in this kind of software architecture from academia and practitioners. The results obtained outline how architectural smells refactoring has to be carefully taken into account in order to improve software quality and reduce technical debt.

In software engineering, automated tools are essential for detecting policy violations within code. These tools typically analyze the relationships and dependencies between components in large codebases, which may be written in various programming languages. Most available tools, whether free or proprietary, rely on third-party software to perform statistical analyses. This approach often requires a separate tool for each programming language, which can lead to high maintenance efforts, and even relying on a standardized technology such as Language Servers has several drawbacks. This paper investigates the feasibility of removing language-specific dependencies in the construction of dependency graphs by using two libraries: Tree Sitter and Stack Graph. After analyzing the capabilities of these technologies, their application in this context is demonstrated, and the effectiveness and accuracy of the proposed solution are evaluated.

Context: Architectural smells, are a well-known indicator of architectural technical debt, their presence could have a great impact on the maintainability and evolvability of a project. Hence, it is important to carefully study and monitor them. Objective: In this paper, we describe an empirical study on the analysis of the correlations existing between architectural smells and co-changes, with the aim of getting further insights into how architectural smells can influence maintenance efforts. Method: Using the Goal-Question-Metric approach, we compared pairs of files affected by smells with clean ones to determine if smelly pairs co-change more frequently. To collect the data, we exploit a new data collection pipeline based on Apache Airflow to generate large-scale, up-to-date datasets with static analysis tools. For the current study, the pipeline uses Arcan 2 , a static analysis tool for architectural smell detection. Results: The empirical study, conducted on a set of projects analyzed by the pipeline, found that the median Co-change rate in smelly (both files affected) and mixed (one file affected) pairs was higher than in clean pairs. Moreover, the Co-change rate of the smelly pairs is higher than that of the mixed ones. This result became more significant as the lines of code increased. Conclusion: The empirical study found that architectural smells are linked to higher Co-change rates in affected files, leading to increased maintenance efforts for developers. Moreover, the results highlight the value of the pipeline data and offer useful insights for managing architectural technical debt.

Context: Aiming for a trade-off between short-term efficiency and long-term stability, software teams resort to sub-optimal solutions, neglecting the best software development practices. Such solutions may induce technical debt (TD), triggering maintenance issues. To facilitate future fixing, developers mark code with any issues using textual comments, resulting in Self-Admitted Technical Debt (SATD). Detecting SATD in source code is crucial since it helps programmers locate potentially erroneous snippets, allowing for suitable interventions, and improving code quality. There are two main types of SATD detection, i.e., binary classification and multi-class classification , grouping TD comments into SATD/Non-SATD categories, and multiple categories, respectively. Objective: We attempt to understand to which extent state-of-the-art research has addressed the issue of detecting SATD, both binary and multi-class classification. Based on this investigation, we also propose a practical approach for the detection of SATD using Large Language Models (LLMs). Methods: First, we conducted a literature review to understand to which extent the two types of classification have been tackled by existing research. Second, we developed SALA , a dual-purpose tool on top of Natural Language Processing (NLP) techniques and neural networks to deal with both types of classification. An empirical evaluation has been performed to compare SALA with state-of-the-art baselines. Results: The literature review reveals that while binary classification has been well studied, multi-class classification has not received adequate attention. The empirical evaluation shows that SALA obtains a promising performance, and outperforms the baselines with respect to various quality metrics. Conclusion: We conclude that more effort needs to be spent to tackle multi-class classification of SATD. To this end, LLMs hold the potential, albeit with more rigorous investigation on possible fine-tuning and prompt engineering strategies.

Abstract Software quality assurance is essential during software development and maintenance. Static Analysis Tools (SAT) are widely used for assessing code quality. Architectural smells are becoming more daunting to address and evaluate among quality issues. We aim to understand the relationships between Static Analysis Warnings (“warnings”) and Architectural Smells (“smell”) to guide developers/maintainers in focusing their effort on warnings more prone to co-occurring with smell. We performed an empirical study on 103 Java projects totaling 72 million LOC belonging to projects from a vast set of domains, and 785 warnings were detected by three SAT, Checkstyle, Findbugs, PMD, SonarQube, and 4 architectural smells were detected by the ARCAN tool. We analyzed how warnings influence smell presence. Finally, we proposed a smell remediation effort prioritization based on warning severity and warning proneness to specific smells. Our study reveals a moderate correlation between warnings and smells. Different combinations of SATs and warnings significantly affect smell occurrence, with certain warnings more Likely to co-occur with specific smells. Conversely, 33.79% of warnings are “non-co-occurring” with any of the smells in our dataset. This provides an early indicator for potential architectural concerns before resource-intensive architectural analysis is performed. Practitioners can ignore about a third of warnings and focus on those most likely to be associated with smells. Prioritizing smell remediation based on warning severity or warning proneness to specific smells results in effective rankings like those based on smell severity. While not a substitute for specialized tools like ARCAN, warning-based prioritization provides a pragmatic bridge between low-level warnings and high-level architectural issues, particularly useful in contexts lacking full architectural visibility.

Architectural smells have been studied in the literature looking at several aspects, such as their impact on maintainability as a source of architectural debt, their correlations with code smells, and their evolution in the history of complex projects. The goal of this paper is to extend the study of architectural smells from a different perspective. We focus our attention on software performance, and we aim to quantify the impact of architectural smells as support to explain the root causes of system performance hindrances. Our method consists of a study design matching the occurrence of architectural smells with performance metrics. We exploit state-of-the-art tools for architectural smell detection, software performance profiling, and testing the systems under analysis. The removal of architectural smells generates new versions of systems from which we derive some observations on design changes improving/worsening performance metrics. Our experimentation considers two complex open-source projects, and results show that the detection and removal of two common types of architectural smells yield lower response time (up to ) with a large effect size, i.e., for - of the hotspot methods. The median memory consumption is also lower (up to ) with a large effect size for all the services.

Methods and tools to support quality assessment and code anomaly detection are crucial to enable software evolution and maintenance. In this work, we aim to detect an increase or decrease in code anomalies leveraging on the concept of microstructures, which are relationships between entities in the code. We introduce a tools pipeline, called Cadartis, which uses an innovative immune-inspired approach for code anomaly detection, tailored to the organization's needs. This approach has been evaluated on 3882 versions of fifteen open-source projects belonging to three different organizations and the results confirm that the approach can be applied to recognize a decrease or increase of code anomalies (anomalous status). The tools pipeline has been designed to automatically learn patterns of microstructures from previous versions of existing systems belonging to the same organization, to build a personalized quality profiler based on its codebase. This work represents a first step towards new perspectives in the field of software quality assessment and it could be integrated into continuous integration pipelines to profile software quality during the development process.

A micro-service architecture emphasizes the use of subsystems that are small enough for changing them on the fly. Such architecture supports the continuous evolution of the system because individual services can be updated at different times, making system maintenance flexible. Consequently, the architecturally important properties of micro-services are constituted by service APIs that must be well maintained, with experimental, static, and deprecated versions clearly indicated. Like any software, micro-services can induce technical debt (TD) problems in service API, architecture and source code, if their quality and maintainability have not been asserted beforehand. This paper explores the relationship between TD and micro-services. Specifically, we investigate the role of architectural smells (AS) in open-source micro-service projects, where the architectural debt is principally recognized through the detection of architectural smells in the projects. As tools for this investigation, we used Arcan and Designite. The empirical data for the work is constituted by 20 open-source projects where we analyze the relationship between architecture smells and micro-services.

The detection of performance issues in Java-based applications is not trivial since many factors concur to poor performance, and software engineers are not sufficiently supported for this task. The goal of this manuscript is the automated detection of performance problems in running systems to guarantee that no quality-based hinders prevent their successful usage. Starting from software performance antipatterns, i.e., bad practices (e.g., extensive interaction between software methods) expressing both the problem and the solution with the purpose of identifying shortcomings and promptly fixing them, we develop a framework that automatically detects seven software antipatterns capturing a variety of performance issues in Java-based applications. Our approach is applied to real-world case studies from different domains, and it captures four real-life performance issues of Hadoop and Cassandra that were not predicted by state-of-the-art approaches. As empirical evidence, we calculate the accuracy of the proposed detection rules, we show that code commits inducing and fixing real-life performance issues present interesting variations in the number of detected antipattern instances, and solving one of the detected antipatterns improves the system performance up to 50%.

The past few years saw the rise of microservices studies and best practices, along with wide industrial adoption of this architectural style. We now witness the birth of another challenging topic: microservices quality. Like other kinds of architectures, also microservices suffer from erosion and technical debt, whose symptoms can be the appearance of microservices smells, which impact negatively on the system’s quality, by hindering, for example, its maintainability. In this paper we propose a tool called Aroma, to reconstruct microservices architectures and detect microservices smells, based on the dynamic analysis of microservices execution traces. We describe the main features of the tool, the strategies adopted for microservice smells detection and the first preliminary experimentation.

Architectural anomalies, also known as architectural smells, represent the violation of design principles or decisions that impact internal software qualities with significant negative effects on maintenance, evolution costs and technical debt. Architectural smells, if early removed, have an overall impact on reducing a possible progressive architectural erosion and architectural debt. Some tools have been proposed for their detection, exploiting different methods, usually based only on static analysis. This work analyzes how dynamic analysis can be exploited to detect architectural smells. We focus on two smells, Hub-Like Dependency and Cyclic Dependency, and we extend an existing tool integrating dynamic analysis. We conduct an empirical study on ten projects. We compare the results obtained comparing a method featuring dynamic analysis and the original version of Arcan based only on static analysis to understand if dynamic analysis can be successfully used. The results show that dynamic analysis helps identify missing architectural smells instances, although its usage is hindered by the lack of test suites suitable for this scope.

During the development phase, software programmers usually introduce code that contains issues intentionally left for additional treatment. To allow for future fixing, they mark such code using textual comments, resulting in Self-Admitted Technical Debt (SATD). Detecting SATD contained in source code has become crucial in the development cycle since it helps programmers locate issues that need to be solved, thus improving code quality. We introduce PILOT, a technical debt detector built on top of a combination of different natural language processing (NLP) and machine learning (ML) techniques. First, the semantic among SATD comments is captured using feature extraction steps. Then, neural network algorithms are applied to classify comments, represented as vectors. We built a PILOT prototype with a feed-forward neural network and evaluated it using real-world datasets as proof of concept. The empirical evaluation shows that PILOT obtains an encouraging performance and outperforms a well-established baseline. We anticipate that our tool will come in handy, as once being embedded in the IDE, it can help developers recognize SATD manifested in their code, allowing them to conveniently identify and fix issues.

Abstract Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether thefrequencyandsizeof changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open‐source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts.

Due to limited time, budget or resources, a team is prone to introduce code that does not follow the best software development practices. This code that introduces instability in the software projects is known as Technical Debt (TD). Often, TD intentionally manifests in source code, which is known as Self-Admitted Technical Debt (SATD). This paper presents DebtHunter, a natural language processing (NLP)- and machine learning (ML)- based approach for identifying and classifying SATD in source code comments. The proposed classification approach combines two classification phases for differentiating between the multiple debt types. Evaluations over 10 open source systems, containing more than 259k comments, showed that the approach was able to improve the performance of others in the literature. The presented approach is supported by a tool that can help developers to effectively manage SATD. The tool complements the analysis over Java source code by allowing developers to also examine the associated issue tracker. DebtHunter can be used in a continuous evolution environment to monitor the development process and make developers aware of how and where SATD is introduced, thus helping them to manage and resolve it.

Technical debt (TD) has been recognized as an important quality problem for both software architecture and code. The evolution of TD techniques over the past years has led to a number of research and commercial tools. In addition, the increasing trend of opportunistic reuse (as opposed to systematic reuse), where developers reuse code assets in popular repositories, is changing the way components are selected and integrated into existing systems. However, reusing software opportunistically can lead to a loss of quality and induce TD, especially when the architecture is changed in the process. However, to the best of our knowledge, no studies have investigated the impact of opportunistic reuse in TD. In this paper, we carry out an exploratory study to investigate to what extent reusing components opportunistically negatively affects the quality of systems. We use one commercial and one research tool to analyze the TD ratios of three case systems, before and after opportunistically extending them with open-source software.

Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring of Technical Debt should be prioritized with respect to developing features or fixing bugs. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. We conducted a Systematic Literature Review of 557 unique papers published until 2020, following a consolidated methodology applied in software engineering. We included 44 primary studies. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools. We observed that Technical Debt prioritization research is preliminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research conclusive. In this paper, we therefore outline different directions for necessary future investigations.

Code smells are poor implementation choices applied by developers during software evolution that often lead to critical flaws or failure. Much in the same way, community smells reflect the presence of organizational and socio-technical issues within a software community that may lead to additional project costs. Recent empirical studies provide evidence that community smells are often-if not always-connected to circumstances such as code smells. In this paper we look deeper into this connection by conducting a mixed-methods empirical study of 117 releases from 9 open-source systems. The qualitative and quantitative sides of our mixed-methods study were run in parallel and assume a mutually-confirmative connotation. On the one hand, we survey 162 developers of the 9 considered systems to investigate whether developers perceive relationship between community smells and the code smells found in those projects. On the other hand, we perform a fine-grained analysis into the 117 releases of our dataset to measure the extent to which community smells impact code smell intensity (i.e., criticality). We then propose a code smell intensity prediction model that relies on both technical and community-related aspects. The results of both sides of our mixed-methods study lead to one conclusion: community-related factors contribute to the intensity of code smells. This conclusion supports the joint use of community and code smells detection as a mechanism for the joint management of technical and social problems around software development communities.

Self-Adaptive Systems are usually built of a managed part, implementing their functionality, and a managing part, implementing their self-adaptation. The complexity of self-adaptive systems results also from the existence of the managing part and the interaction between the managed and the managing parts. The nonself- adaptive systems may be seen as the managed part of self-adaptive systems. The self-adaptive systems are evaluated based on their performances resulted from the self-adaptation. However, self-adaptive systems are software systems, hence, also their software quality is equally important. Our analysis compares the internal quality of self-adaptive and non-self-adaptive systems by considering code smells, architectural smells, and GoF's design patterns. This comparison provides an insight to the health of the self-adaptive systems with respect to the non-self-adaptive systems (the last being considered as a quality reference).

With the adoption of microservices architectural styles, practitioners started noticing increasing pitfalls in managing and maintaining such architectures, with the risk of introducing architectural debt. Previous studies identified different microservice smells (also named anti-patterns) that harm microservices architectures. However, according to our knowledge, there are no tools that can automatically detect microservice smells, so their identification is left to the experience of the developer. In this paper, we extend an existing tool developed for the detection of architectural smells to explore microservices architecture through the detection of three microservice smells: Cyclic Dependencies, Hard-Coded Endpoints, and Shared Persistence. We detected the smells on five open-source projects implemented with microservices and manually validated the precision of the detection results. This work aims to open new perspectives on facing and studying architectural debt in the field of microservices architectures.

Architectural smells can be detrimental to the system maintainability, evolvability and represent a source of architectural debt. Thus, it is very important to be able to understand how they evolved in the past and to predict their future evolution. In this paper, we evaluate if the existence of architectural smells in the past versions of a project can be used to predict their presence in the future. We analyzed four Java projects in 295 Github releases and we applied for the prediction four different supervised learning models in a repeated cross-validation setting. We found that historical architectural smell information can be used to predict the presence of architectural smells in the future. Hence, practitioners should carefully monitor the evolution of architectural smells and take preventative actions to avoid introducing them and stave off their progressive growth.

Architectural smells can negatively impact on different software qualities and can represent a relevant source of architectural debt. Several architectural smells have been defined by different researchers. Moreover, both academia and industry proposed several tools for software quality analysis, but it is not always clear to understand which tools provide also support for architectural smells detection and if the tools developed for this specific purpose are effectively available or not. In this paper we propose a catalogue of architectural smells for which, at least one tool able to detect the smell exists. We outline the main differences in the detection techniques exploited by the tools and we propose a classification of these architectural smells according to the violation of three design principles.

Architectural smells may substantially increase maintenance effort and thus require extra attention for potential refactoring. While we currently understand this concept and have identified different types of such smells, we have not yet studied their evolution in depth. This is necessary to inform their prioritisation and refactoring. This study analyses the evolution of individual architectural smell instances over time, and the characteristics that define these instances. Three different types of architectural smells are taken into consideration and mined from a total of 524 versions across 14 different projects. The results show how different smell types differ in multiple aspects, such as their growth rate, the importance of the affected elements over time in the dependency network of the system, and the time each instance affects the system. They also cast valuable insights on what aspects are the most important to consider during prioritisation and refactoring activities.

The assessment of software quality is one of the most multifaceted (eg, structural, product, and process quality) and subjective aspects of software engineering, as in most cases, it is substantially based on expert judgement. Such assessments can be performed at almost all phases of software development (from project inception to maintenance) and at different levels of granularity (from source code to architecture). However, human judgement is (1) inherently biased by implicit, subjective criteria applied in the evaluation process, and (2) its economical effectiveness is limited compared to automated or semi­automated approaches. For these reasons, the research community is still looking for new, more effective methods of assessing various qualitative characteristics of software systems and the related processes. In recent years, we observed a rising interest in adopting various approaches to exploiting machine learning (ML) and automated decision­making processes in several areas of software engineering. These models and algorithms help to reduce effort and risk related to human judgment in favor of automated systems, which are able to make informed decisions based on available data and evaluated with objective criteria. Thus, the adoption of machine learning techniques seems to be one of the most promising ways to improve software quality evaluation. This special issue aims at providing researchers with the possibility to spread novel ideas and methods to make machine learning actionable for the assessment of software quality artifacts and processes. The call for papers was originally published in SE­WORLD, the journal webpage, and other forums relevant to the software engineering community. We particularly encouraged the authors of papers accepted at the 2nd International Workshop on Machine Learning for Software Quality Evaluation (MaLTeSQuE 20181) to submit a revised, extended version of the workshop papers. All submitted papers went through a rigorous review process, which involved up to three internationally recognized experts of the field. This ensured rigor, novelty, and the scientific contribution expected by the Journal of Software: Evolution and Process. As a result, out of the six submitted papers, four of them were recommended for publication. It is our hope that the papers presented in this special issue will further foster the research community toward the intersection between machine learning and software quality assessment. We would like to thank the Editor­in­Chief of the Journal of Software: Evolution and Process, Professor Gerardo Canfora, for allowing us to present this special issue. We are very grateful to all our reviewers for their efforts in evaluating the submitted papers as well as for their timely and constructive reviews that have helped the authors to substantially improve the quality of their works. Finally, we would like to thank the authors who have submitted and revised their papers according to the reviewers' feedback and who have made this special issue possible.

Code smells are symptoms of poor design and implementation choices. Previous studies empirically assessed the impact of smells on code quality and clearly indicate their negative impact on maintainability, including a higher bug-proneness of components affected by code smells. In this paper, we capture previous findings on bug-proneness to build a specialized bug prediction model for smelly classes. Specifically, we evaluate the contribution of a measure of the severity of code smells (i.e., code smell intensity) by adding it to existing bug prediction models based on both product and process metrics, and comparing the results of the new model against the baseline models. Results indicate that the accuracy of a bug prediction model increases by adding the code smell intensity as predictor. We also compare the results achieved by the proposed model with the ones of an alternative technique which considers metrics about the history of code smells in files, finding that our model works generally better. However, we observed interesting complementarities between the set of buggy and smelly classes correctly classified by the two models. By evaluating the actual information gain provided by the intensity index with respect to the other metrics in the model, we found that the intensity index is a relevant feature for both product and process metrics-based models. At the same time, the metric counting the average number of code smells in previous versions of a class considered by the alternative model is also able to reduce the entropy of the model. On the basis of this result, we devise and evaluate a smell-aware combined bug prediction model that included product, process, and smell-related features. We demonstrate how such model classifies bug-prone code components with an F-Measure at least 13 percent higher than the existing state-of-the-art models.

Architectural smells gained great attention in the past few years since they directly affect software quality and increase architectural technical debt. However, while it is straightforward to understand why they are important, it is more difficult to find techniques and tools to detect and remove architectural smells. The purpose of this paper is to introduce an open-source tool for automatic architectural smells detection for C/C++ projects, by creating an abstraction of the project and defining the concept of dependency between elements belonging to the project in order to identify architectural smells. The tool has been validated on some open-source projects with promising results.

Different indexes have been proposed to evaluate software quality and technical debt. Usually these indexes take into account different code level issues and several metrics, well known software metrics or new ones defined ad hoc for a specific purpose. In this paper we propose and define a new index, more oriented to the evaluation of architectural violations. We describe in detail the index, called Architectural Debt Index, that we integrated in a tool developed for architectural smell detection. The index is based on the detection of architectural smells, their criticality and their history. Currently only dependency architectural smells have been considered, but other architectural debt indicators can be considered and integrated in the index computation.

In the last decade, data security has become a primary concern for an increasing amount of companies around the world. Protecting the customer's privacy is now at the core of many businesses operating in any kind of market. Thus, the demand for new technologies to safeguard user data and prevent data breaches has increased accordingly. In this work, we investigate a machine learning-based approach to automatically extract sources and sinks from arbitrary Java libraries. Our method exploits several different features based on semantic, syntactic, intra-procedural dataflow and class-hierarchy traits embedded into the bytecode to distinguish sources and sinks. The performed experiments show that, under certain conditions and after some preprocessing, sources and sinks across different libraries share common characteristics that allow a machine learning model to distinguish them from the other library methods. The prototype model achieved remarkable results of 86% accuracy and 81% F-measure on our validation set of roughly 600 methods.

Static source code analysis is an increasingly important activity to manage software project quality, and is often found as a part of the development process. A widely adopted way of checking code quality is through the detection of violations to specific sets of rules addressing good programming practices. SonarQube is a platform able to detect these violations, called Issues. In this paper we described an empirical study performend on two industrial projects, where we used Issues extracted on different versions of the projects to predict changes in code through a set of machine learning models. We achieved good detection performances, especially when predicting changes in the next version. This result paves the way for future investigations of the interest in an industrial setting towards the prioritization of Issues management according to their impact on change-proneness.

Software development is more and more influenced by the usage of FLOSS (Free, Libre and Open Source Software) projects. These software projects are developed in web collaborative environments hosted on web platforms, called code forges. Many code forges exist, with different capabilities. GitHub is perhaps the largest code forge available, and many projects have been migrated from different code forges to GitHub. Given its success, we want to understand if its adoption has effect on the projects' internal quality. To consider objective measures of internal quality, we apply four known tools performing static analysis to extract metrics and code anomalies. These data is extracted on six versions of six FLOSS projects, and compared to understand if the migration to GitHub had any consistent effect over any of the considered measures.

GitHub is a platform used for the development of software projects. It provides a traceable project repository and a social meeting place for communities of practices. This poster presents the students' feedback on using GitHub as a development platform for software projects counting as an exam for a 3rd-year undergraduate software engineering course on software design. Students worked in teams and their feedback is positive overall.

To better understand and exploit the knowledge necessary to comprehend and evolve an existing system, different models can be extracted from it. Models represent the extracted information at various abstraction levels, and are useful to document, maintain, and reengineer the system. The Knowledge Discovery Metamodel (KDM) has been defined by the object management group as a meta-model supporting a large share of reverse engineering activities. Its specification has also been adopted by the ISO in 2012. This paper explores and describes alternative meta-models proposed in the literature to support reverse engineering, program comprehension, and software evolution activities. We focus on the similarity and differences of the alternative meta-models with KDM, trying to understand the potentials of reciprocal information interchange. We describe KDM and other five meta-models, plus their extensions available in the literature and their diffusion in the reverse engineering community. We also investigate the approaches using KDM and the five meta-models. In the paper, we underline the limited reuse of models for reverse engineering, and identify potential directions for future related research, to enhance the existing models and ease the exchange of information among them.

Code smells represent well known symptoms of problems at code level, and architectural smells can be seen as their counterpart at architecture level. If identified in a system, they are usually considered more critical than code smells, for their effect on maintainability issues. In this paper, we introduce a tool for the detection of architectural smells that could have an impact on the stability of a system. The detection techniques are based on the analysis of dependency graphs extracted from compiled Java projects and stored in a graph database. The results combine the information gathered from dependency and instability metrics to identify flaws hidden in the software architecture. We also propose some filters trying to avoid possible false positives.

Code smells are symptoms of poor design and implementation choices. Previous studies empirically assessed the impact of smells on code quality and clearly indicate their negative impact on maintainability, including a higher bug-proneness of components affected by code smells. In this paper we capture previous findings on bug-proneness to build a specialized bug prediction model for smelly classes. Specifically, we evaluate the contribution of a measure of the severity of code smells (i.e., code smell intensity) by adding it to existing bug prediction models and comparing the results of the new model against the baseline model. Results indicate that the accuracy of a bug prediction model increases by adding the code smell intensity as predictor. We also evaluate the actual gain provided by the intensity index with respect to the other metrics in the model, including the ones used to compute the code smell intensity. We observe that the intensity index is much more important as compared to other metrics used for predicting the buggyness of smelly classes.

Anti-patterns and code smells are archetypes used for describing software design shortcomings that can negatively affect software quality, in particular maintainability. Tools, metrics and methodologies have been developed to identify these archetypes, based on the assumption that they can point at problematic code. However, recent empirical studies have shown that some of these archetypes are ubiquitous in real world programs, and many of them are found not to be as detrimental to quality as previously conjectured. We are therefore interested in revisiting common anti-patterns and code smells, and building a catalogue of cases that constitute candidates for "false positives". We propose a preliminary classification of such false positives with the aim of facilitating a better understanding of the effects of anti-patterns and code smells in practice. We hope that the development and further refinement of such a classification can support researchers and tool vendors in their endeavour to develop more pragmatic, context-relevant detection and analysis tools for anti-patterns and code smells.

Architecture erosion constitutes the most visible effect of the degradation of design. It is a major reason to address the design debt, often caused by architectural mismatch problems. Today, the identification of design erosion is a major concern for designers and software maintainers. Adequate tools are necessary to identify and repair the debt. This paper describes our experience on identifying architectural erosion problems on existing open source software applications through the support of two well known tools. Moreover, we outline if the tools provide useful hints in repairing some of the detected problems.

Many tools for code smell detection have been devel- oped, providing often different results. This is due to the informal definition of code smells and to the subjective interpretation of them. Usually, aspects related to the domain, size, and design of the system are not taken into account when detecting and analyzing smells. These aspects can be used to filter out the noise and achieve more relevant results. In this paper, we propose different filters that we have identified for five code smells. We provide two kind of filters, Strong and Weak Filters, that can be integrated as part of a detection approach.

The presence of anti-patterns and code smells can affect adversely software evolution and quality. Recent work has shown that code smells that appear together in the same file (i.e., collocated smells) can interact with each other, leading to various types of maintenance issues and/or to the intensification of negative effects. It has also been found that code smell interactions can occur across coupled files (i.e., coupled smells), with comparable negative effects as the interaction of same-file (collocated) smells. Different inter-smell relations have been described in previous work, yet only few studies have evaluated them empirically. This study attempts to replicate the findings from previous work on inter-smell relations by analyzing larger systems, and by including both industrial and open source ones. We also include the analysis of coupled smells in addition to collocated smells, to achieve a more complete picture of inter-smell relations. Our results suggest that if coupled smells are not considered, one may risk increasing the number of false negatives when analysing inter-smells. A major finding is that patterns of inter-smell relations vary between open source and industrial systems, suggesting that contextual variables should be considered in further studies on code smells.

Version Control Systems (VCSs) provide historical information that can be used to perform deep analyses on the evolution of a software project, with the aim of enhancing the quality of the system and predicting software evolution.

Previous research determined that the analysis of file changes in software repositories is useful for maintenance activities, like defect prediction. Changes rarely modify the entire file contents, but are usually localized in specific code regions.

In this paper, an approach for information systems reverse engineering is proposed and applied. The aim is to support a unified perspective to the reverse engineering process of both data and software. At the state of the art, indeed, many methods, techniques, and tools for software reverse engineering have been proposed to support program comprehension, software maintenance, and software evolution. Other approaches and tools have been proposed for data reverse engineering, with the aim, for example, to provide complete and up-to-date documentation of legacy databases. However, the two engineering communities often worked independently, and very few approaches addressed the reverse engineering of both data and software as information system's constituencies. Hence, a higher integration is needed to support a better co-evolution of databases and programs, in an environment often characterized by high availability of data and volatility of information flows. Accordingly, the approach we propose leverages the detection of object-relational mapping design patterns to build a conceptual schema of the software under analysis. Then, the conceptual schema is mapped to the domain model of the system, to support the design of the evolution of the information system itself. The approach is evaluated on two large-scale open-source enterprise applications. Copyright © 2014 John Wiley & Sons, Ltd.

There are various activities that support software maintenance. Program comprehension and detection of design anomalies and their symptoms, like code smells and anti patterns, are particularly relevant for improving the quality and facilitating evolution of a system. In this paper we describe an empirical study on the detection of code smells, aiming at identifying the most frequent smells in systems of different domains and hence the domains characterized by more smells. Moreover, we study possible correlations existing among smells and the values of a set of software quality metrics using Spearman's rank correlation and Principal Component Analysis.

Several code smells detection tools have been developed providing different results, because smells can be subjectively interpreted and hence detected in different ways. Usually the detection techniques are based on the computation of different kinds of metrics, and other aspects related to the domain of the system under analysis, its size and other design features are not taken into account. In this paper we propose an approach we are studying based on machine learning techniques. We outline some common problems faced for smells detection and we describe the different steps of our approach and the algorithms we use for the classification.

SUMMARY Design patterns play a significant role in reverse engineering by providing information not only on how but also on why a solution has been implemented in a specific way because of their semantics. The application of design patterns leads to their personalization to a specific context, hence to the generation of variants. This makes their recognition a challenging task, which may be addressed through the understanding and detection of the micro‐structures design patterns are made of. This is very useful for the detection as well as for the application of design patterns. The principal aim of this paper is to present a survey on these micro‐structures and a comparison among them in the perspective of reverse engineering. Because of their less complex structure and behavior, as well as closer link to the source code, the recognition of these micro‐structures may be automated, which can be considered a step towards the automatic recognition of the more complex design patterns. In this paper, we consider four of the most significant types of micro‐structures: elemental design patterns, clues, sub‐patterns, and micro patterns. To analyze the role of the micro‐structures in the design pattern detection process, we make a comparison among these four types of micro‐structures and among the micro‐structures of various types in order to identify the relations among them. Copyright © 2011 John Wiley & Sons, Ltd.

In the context of software evolution, many activities are involved and are very useful, like being able to evaluate the design quality of an evolving system, both to locate the parts that need particular refactoring or reengineering efforts, and to evaluate parts that are well designed. This paper aims to give support hints for the evaluation of the code and design quality of a system and in particular we suggest to use metrics computation and antipatterns detection together. We propose metrics computation based on particular kinds of micro-structures and the detection of structural and object-oriented antipatterns with the aim of identifying areas of design improvements. We can evaluate the quality of a system according to different issues, for example by understanding its global complexity, analyzing the cohesion and coupling of system modules and locating the most critical and complex components that need particular refactoring or maintenance.

Currently, research on reverse engineering and automated design pattern detection focuses mostly on some of the programming languages such as Java and C/C++, with marginal interest in the .NET area. In this paper, we present a tool for analyzing .NET executables for architecture reconstruction in general and design pattern detection in particular. The tool extracts the meaningful information from .NET systems and produces an output compatible with the design pattern detection tool we are developing for Java software, tool called MARPLE (Metrics and Architecture Reconstruction PLug-in for Eclipse).

In this paper we face some relevant issues on the relations between Web communities and ontologies. We build an operator that constructs a weak Web community, according to the definition given in,starting from a seed of Web sites. The necessity of such an operator is derived from a problem arisen in the model developed in, in which some relevant concepts in automotive oriented ontology were not given a corresponding Web community. This fact -if not considered- can bring automatic ontology development to some non-correct results. In this work we define and analyze a new operator, called Com, with the tools furnished by the method of parametrization and we find that, given a seed S and the induced graph I(S), the community generated by our operator is monotonic with respect to clustering and is denser than the original graph I(S).

The main goal of the RE4APM working session is to discuss the main issues and critical problems involved in application portfolio management (APM), which can be supported through advanced reverse engineering techniques and to promote collaborations among the international communities from both universities and industry.

Java PathFinder (JPF) is an explicit state model checker developed by the Automated Software Engineering Group of NASA of the AMES Research Center (California). Eclipse is probably the most important and used Java integrated developing environment (IDE) and not only; it is a framework/environment that can be easily extended with new functionalities by exploiting its plug-in mechanism. Through a JPF plug-in for Eclipse it is possible to integrate powerful model checking and testing capabilities into the development environment. This paper presents the re-design of the standalone version of JPF towards an Eclipse plug-in exploiting and outlining in this way the advantages of an open source development

We propose an extension of the resolution rule as the core of a logic programming language based on similarity. Starting from a fuzzy unification algorithm described in Ref. 2 and then extended in Ref. 10, we introduce a fuzzy resolution rule, based on an extended most general unifier supplied by the extended unification algorithm. In our approach, unification fades into a unification degree because of a similarity introduced in a first-order language. Intuitively, the unification degree of a set of first-order terms is the cost one has to pay to consider these terms as equal. For this reason, our extension of the resolution is more structured than its classic counterpart;that is, when the empty clause is reached, in addition to a computed answer, a set of conditions is also determined. We give both the operational and fixed-point semantics of our extended logic programming language, and we prove their equivalence. © 2002 Wiley Periodicals, Inc.

Techniques that optimize computations by reusing partial results have a long tradition in computer science. Seen from the point of view of sequential computations, all these techniques share the common execution strategy of storing partial results in a centralized data structure, while they differ as to how the results are computed, e.g. in a data-driven or constraint-driven fashion. Concurrent systems, namely the wide variety of systems that range from fine-grained parallelism to coarse-grained distribution, add another variable into the game. In fact, information reuse is here tangled with issues of local memory of agents and inter-agent communication. Thus, optimal strategies for information reuse directly affect agent configurations as well as agent communication protocols and strictly depend on those morphological aspects of the computational domain related to the sharing of structures among different data values. In this paper, we define a formal framework suitable for the study of information reuse from the point of view of concurrent systems. The main result of our work is in the identification of two distinct morphological features of computational domains, namely recursively replicated structures and structure copying. These features induce two different forms of information reuse that can be optimized, respectively, by solipsistic agents with large local memory and by large bandwidth networks of collaborative agents.