Abstract Mobile device applications (apps) are complex because they rely on integrating multiple third-party libraries (TPLs). Yet, TPLs ease app development by offering implementations of specific functionality. For example, app developers often use advertising libraries to generate revenue, integrate social networking libraries to simplify login, or include crash reporting libraries to monitor/report crashes in their apps. However, there are multiple TPLs with similar functionalities from which to choose, and developers often cannot foresee all the consequences of using these libraries in their apps. The sizes of apps grow with the addition and usage of TPLs, and so does the number of required permissions and resource consumption. Thus, TPLs may degrade the quality of apps and developers need help measuring and comparing them. We propose EQuAT, an approach for Evaluating Quality Attributes of TPLs that eases the comparison of TPLs. EQuAT takes as input minimal apps that integrate TPLs and playable scenarios to simulate user interaction while exercising a particular functionality of the included TPL. By collecting quality metrics and comparing them using plots, we provide app developers with a systematic approach to rank TPLs based on their preferences. We show how EQuAT helps developers make informed decisions about which libraries to integrate into their apps by validating them against nine TPLs across three categories.

Internet of Things (IoT) systems are pervasive and increasingly managed through mobile applications. However, poorly designed mobile applications can expose sensitive information to external adversaries. Mitigating such vulnerabilities requires both developers and researchers to apply well-established practices and design secure systems based on clearly defined approaches for vulnerability detection. Although databases such as Open Worldwide Application Security Project (OWASP) and Common Vulnerabilities and Exposures (CVE) catalog known IoT vulnerabilities, no standardised methodology exists for detecting security weaknesses in IoT Mobile applications (IoTMas) during IoT mobile application development. Building on prior research, our research objectives are to: (1) identify, classify, and prioritize critical security vulnerabilities in IoTMAs, (2) survey existing Vulnerability Detection Approaches (VDAs) for IoT mobile applications, (3) critically evaluate the effectiveness of existing VDAs by analyzing their evaluation methodologies and dataset validation, and (4) formulate evidence-based recommendations based on the limitations of existing methods for detecting security vulnerabilities in IoTMAs. We performed a systematic literature review (SLR) from selected primary studies (PSs). From 856 papers retrieved from six academic databases—Scopus, Springer, and Engineering Village, which hosts Compendex (covering IEEE Xplore and the ACM Digital Library), and Inspec (IET)—we reviewed 39 research papers. Our findings include: (1) identification of 52 security vulnerabilities, eight critical (i.e, reported in at least four studies); (2) discovery of seven distinct VDAs; (3) comprehensive VDAs effectiveness evaluation using empirical metrics, accuracy assessments, reproducibility analysis, comparative studies, and validation across diverse IoTMAs marketplaces; (4) recommendations to guide developers and practitioners in selecting appropriate VDAs, thereby supporting the development of secure IoTMAs and enhanced penetration testing. Our study raises awareness of state-of-the-art VDAs, identifies research gaps in existing approaches, and provides recommendations to enhance existing techniques and guide new development, supporting software engineers in making informed technique selection decisions.

ABSTRACT Objective Antipatterns (APs) represent potential issues in software systems stemming from poor design choices, coding practices, and undisciplined development. This systematic literature review analyzes 97 primary studies (PSs) from 2005 to 2024, exploring the impact of APs on Object‐Oriented (OO), Service‐Oriented (SO), and Mobile‐Oriented (MO) systems across various quality attributes. Methods PSs are classified by techniques, datasets, evaluation measures, and tool support. Result Findings highlight the association of APs with increased maintenance costs (27.8%), fault‐proneness (26.8%), change‐proneness (12.3%), and evolution challenges (25.7%). Most studies employ descriptive statistics, regression analysis, and Pearson correlation, with limited datasets and tool support for SO and MO systems compared to OO systems. Intermediate source code representations and program comprehension strategies are commonly used for analysis. Conclusion These findings emphasize the need for further research on the impact of APs, particularly in MO systems, and their negative effects on software quality attributes.

Internet of Things (IoT) systems refer to interconnected systems of devices that collect, process, and exchange data. As IoT adoption continues to grow, ensuring effective testing is of paramount importance. However, testing IoT systems remains a challenge, particularly for software engineers, due to the need to test aspects beyond their primary area of expertise (e.g., security, sensor calibration, and connectivity). Testing aspects refer to any concept or concern that should be considered when testing a given system. While several frameworks for testing exist that focus on generic aspects of IoT systems, there is no dedicated framework for testing technical software engineering (SE) aspects of IoT systems. To address this gap, we propose and evaluateTISSEA, a framework to guide software engineers to test the technical software engineering (SE) aspects of IoT systems. We constructed TISSEA by identifying all possible technical software-engineering aspects from published taxonomies for IoT systems testing. Further, we mapped each aspect to the granularity of testing at each layer of the IoT system. We finally mapped each aspect with test orchestration strategies, test input artifacts, and execution strategies. We evaluated the TISSEA by surveying 22 professionals and conducting two case studies: (1) event logging and handling testing and (2) data integrity testing. The survey results show that professionals agreed with the proposed technical SE aspects for testing the device and application layers. However, the aspects proposed for testing the gateway and cloud layers still require further investigation. Results of the case studies indicate a gap between expected and captured log events. Regarding event handling, we found that some of the events reported by the system as successfully handled may include unhandled events that cannot be identified when relying on a single orchestration strategy. Regarding data integrity testing, we found that data can be altered at any node at any layer of the IoT system. However, accessing the original data allows the detection of modifications made to it at each node. Overall evaluation of TISSEA shows strong agreement with practitioners, and it could usefulness to test technical software engineering aspects of IoT systems.

The Internet of Things (IoT) is reshaping our lives, increasing the need for thorough pre-deployment testing. However, traditional software testing may not address the testing requirements of IoT systems, leading to quality challenges. A specific testing taxonomy is crucial, yet no widely recognized taxonomy exists for IoT system testing. We introduced an IoT-specific testing taxonomy that categorizes aspects of IoT systems testing into seven distinct categories. We mined testing aspects from 83 primary studies in IoT systems testing and built an initial taxonomy. This taxonomy was refined and validated through two rounds of surveys involving 16 and then 204 IoT industry practitioners. We assessed its effectiveness by conducting an empirical evaluation on two separate IoT systems, each involving 12 testers. Our findings categorize seven testing aspects: (1) testing objectives, (2) testing tools and artifacts, (3) testers, (4) testing stage, (5) testing environment, (6) Object Under Test (OUT) and metrics, and (7) testing approaches. The evaluation showed that testers equipped with the taxonomy could more effectively identify diverse test cases and scenarios. Additionally, we recommend new research opportunities to enhance the testing of IoT systems. • Conducted a literature review of 83 primary studies to develop an initial taxonomy for testing IoT systems, comprising seven key aspects: testing objectives, tools and artifacts, testers, stages, environments, Object Under Test (OUT), and testing approaches. • Refined and validated the proposed taxonomy through surveys involving 16 and 204 IoT industry practitioners. • Conducted an empirical evaluation using two case studies and 12 practitioners for each to assess the taxonomy’s effectiveness. • Provided structured guidance for practitioners to navigate and apply the taxonomy effectively. • Discussed insights from the empirical evaluation and offered recommendations for practitioners and researchers. • Set up two public access points for professionals to continuously access and stay updated with our IoT systems testing taxonomy. The first is hosted on the Ptidej website, while the second is available in a GitHub repository, ensuring that the latest version, incorporating newly identified aspects, is always accessible.

The migration of legacy software systems to aservice-oriented architecture(SOA) is one of the main strategies for modernising such systems. The success of modernising a legacy system to a SOA highly depends on the used service identification approach where the goal is to identify reusable functionalities that could become services. In this paper, we perform a comparative analysis of service identification approaches proposed by academia and industry. We show that there is a gap between academia and industry in the used approaches to identify services from legacy systems. We extract from the comparative analysis several recommendations about the inputs, processes, and outputs that a service identification approach should have. Based on these recommendations, we proposeServiceMiner, a bottom-up service identification approach, which relies on source-code analysis, because other sources of information may be unavailable or out of sync with the actual code.ServiceMinerrelies on a categorisation of service types and code-level patterns characterising types of services. We evaluateServiceMineron four case studies. We also compare our results to those of three state-of-the-art approaches. We show thatServiceMineridentifies architecturally-significant services with, on average, 78% precision, 76% recall, and 77% F-measure.

Scalability and maintainability challenges in monolithic systems have led to the adoption of microservices, which divide systems into smaller, independent services. However, migrating existing monolithic systems to microservices is a complex and resource-intensive task, which can benefit from machine learning (ML) to automate some of its phases. Choosing the right ML approach for migration remains challenging for practitioners. Previous works studied separately the objectives, artifacts, techniques, tools, and benefits and challenges of migrating monolithic systems to microservices. No work has yet investigated systematically existing ML approaches for this migration to understand the automated migration phases, inputs used, ML techniques applied, evaluation processes followed, and challenges encountered.We present a systematic literature review (SLR) that aggregates, synthesises, and discusses the approaches and results of 81 primary studies (PSs) published between 2015 and 2024. We followed the Preferred Reporting Items for Systematic Review and Meta-Analysis (PRISMA) statement to report our findings and answer our research questions (RQs).We extract and analyse data from these PSs to answer our RQs. We synthesise the findings in the form of a classification that shows the usage of ML techniques in migrating monolithic systems to microservices. The findings reveal that some phases of the migration process, such as monitoring and service identification, are well-studied, while others, like packaging microservices, remain unexplored. Additionally, the findings highlight key challenges, including limited data availability, scalability and complexity constraints, insufficient tool support, and the absence of standardized bench-marking, emphasizing the need for more holistic solutions.

Monolithic software systems face significant challenges in terms of maintenance, scalability, and portability. To address these challenges, many companies are embracing the microservices architectural style as a more flexible alternative to their monoliths. Microservices structure systems into modular, independent components, enabling easier development, deployment, and maintenance. However, the migration from a monolith to microservices is challenging due to the laborious task of manually identifying and decomposing a system into microservices. Several earlier studies focused on developing approaches to facilitate the migration process. However, the reliance on domain experts to define various parameters and thresholds restricted their use. In this paper, we introduce Magnet, a fully automated microservice identification approach, based on graph neural networks (GNNs). Magnet integrates a GNN model with a fine-grained method-based graph enriched with semantic and static features of the system. It enables accurate microservices identification while simultaneously promoting microservice cohesion and reducing microservice coupling. To validate the accuracy of Magnet, we performed extensive experiments using a set of open-source systems. Quantitatively, we use a set of quality metrics to assess the resulting microservices quality. We also compare our results to established ground truths. Empirical evidence suggests that our fully-automated approach Magnet achieves precision and recall rates of 56% and 68%. Qualitatively, we assess the modularity and functional independence of the resulting microservices by examining their relationships and semantic integrity. This evaluation demonstrates that our fully automated approach yields promising results, underlining its effectiveness in creating modular and coherent microservices.

The Internet of Things (IoT) is increasingly prevalent, with systems developed across various domains. Choosing the right IoT architectural style is challenging due to the diversity of devices, dynamic environments, and real-time data needs. This choice significantly impacts system quality, requiring a careful balance of quality requirements and tradeoffs. Previous studies have not adequately identified the most suitable architectural styles for specific IoT quality needs. This study presents a systematic literature review of 103 primary studies (PSs) on IoT system quality requirements and architectural styles, assessing how each architectural style satisfies specific requirements. We followed the preferred reporting items for systematic review and meta-analysis (PRISMA) protocol to report our findings and answer three research questions (RQs). We selected PSs by applying inclusion and exclusion criteria to relevant papers published until the end of 2023. We analyzed data from PSs to understand IoT system quality requirements and architectural styles, assessing their alignment. The research revealed ten essential quality requirements for IoT systems and identified ten distinct architectural styles. Notably, each architectural style varies in its capacity to fulfill specific quality requirements, particularly regarding security, scalability, and performance. SOA, client-server, and REST architectural styles best fulfill many quality requirements. However, various architectural styles, such as Layered, Microservices, and Peer-to-Peer, show limited support for privacy requirements. Our findings can guide IoT systems practitioners in selecting an architectural style that aligns with their desired quality standards. Additionally, we recommend new research opportunities to deepen understanding of key architectural styles based on specific quality requirements.

As the Internet of Things (IoT) grows, its failures may have dramatic consequences on the lives of people who depend on it. Yet, it is hard to test IoT systems before they are deployed. Several researchers have provided state-of-the-art approaches for testing IoT systems. However, many of those approaches are based on academia rather than industry. Therefore, we conducted a multimethod study of IoT systems testing in the industry with IoT practitioners. We used three methods: 1) an industry survey; 2) practitioners interviews; and 3) analysis of Eclipse IoT surveys. This study focuses on testing IoT systems by industry practitioners. The findings show the following. 1) Testing focuses more on the device, network, and application layers. IoT testing gives more importance to integration testing than acceptance testing. Test coverage is the most important metric, but metrics may vary depending on the project. 2) IoT system testing mainly uses the model-based approach and is often manual or semi-automated, with low adoption of white box testing. Node-RED is commonly used in testing IoT systems, while Amazon AWS IoT is popular for cloud platform testing of IoT devices. 3) Log analysis is the main approach to analyzing the root cause of bugs. 4) The main challenges in IoT testing include the lack of standards, security, connectivity, and reference architecture. Generating test cases and establishing a standard test approach are recommended for further research. This study’s findings can help IoT practitioners and researchers to identify and tackle challenges in IoT system testing, leading to future research opportunities.

Buildings consist of systems that have to interact and coordinate with various systems to function smoothly. It is essential to have models and representations of buildings in forms that are easy to read for effective simulation, control, and optimization of building systems. It is also necessary for integrating and creating novel applications and functions. A Building Energy Management System (BEMS) is a common feature of most commercial buildings. It contains models of some aspects of the building and its systems. However, these models in the BEMSs do not entirely model all systems and subsystems and their relationships because their primary function is to control heating, ventilation, air-conditioning (HVAC), and lighting. Project Haystack and Brick have made significant progress in modelling buildings for operational purposes by adopting a metadata approach. They offer machine and human-readable representations of buildings, systems, and their relationships. However, tags and tagsets in the metadata approach have some limitations that stem from a weak structure in defining entities, their properties, and relationships. In this study, we identify seven problems with the metadata approach to modelling buildings and address these problems with an object-oriented metamodel: Metamodel for Energy Things (MetamEnTh). Using an object-oriented modelling technique to establish structure and constraints, MetamEnTh produces a model that portrays a building and its systems. MetamEnTh adheres to the same naming convention of entities as other projects like Project Haystack and Brick. We accomplish a UML representation of the core structure of MetamEnTh and validate the representation through three different case studies.

Internet of Things (IoT) systems are becoming prevalent in various domains, from healthcare to smart homes. Testing IoT systems is critical in ensuring their reliability. Previous papers studied separately the objectives, approaches, tools, and challenges of IoT systems testing. However, despite the rapid evolution of the IoT domain, no review has been undertaken to investigate all four aspects collectively. This paper presents a systematic literature review that aggregates, synthesizes, and discusses the results of 83 primary studies (PSs) concerning IoT testing objectives, approaches, tools, and challenges. We followed the Preferred Reporting Items for Systematic Review and Meta-Analysis (PRISMA) protocol to report our findings and answer research questions (RQs). To select PSs, we applied inclusion and exclusion criteria to relevant studies published between 2012 and 2022. We extracted and analyzed the data from PSs to understand IoT systems testing. The results reveal that IoT systems testing embraces traditional software quality attributes but also introduces new ones like connectivity, energy efficiency, device lifespan, distributivity, and dynamicity. They also show that existing IoT systems testing approaches are limited to specific aspects and should be expanded for more comprehensive testing. They also show 19 testing tools and 15 testbeds for testing IoT systems with their limitations, necessitating the development or enhancement for wider coverage. The large number of heterogeneous devices generating data in different formats, along with the need for testing in real-world scenarios, poses a challenge. Thus, our study offers insights into the testing objectives, approaches, tools, and challenges associated with IoT systems. Based on the results, we also provide practical guidance for IoT practitioners by cataloging existing tools and approaches, while also identifying new research opportunities for interested researchers.

As machine learning expands to various domains, the demand for reusable solutions to similar problems increases. Machine learning design patterns are reusable solutions to design problems of machine learning applications. They can significantly enhance programmers' productivity in programming that requires machine learning algorithms. Given the critical role of machine learning design patterns, the automated detection of them becomes equally vital. However, identifying design patterns can be time-consuming and error-prone. We propose an approach to detect their occurrences in Python files. Our approach uses an Abstract Syntax Tree (AST) of Python files to build a corpus of data and train a refined Text-CNN model to automatically identify machine learning design patterns. We empirically validate our approach by conducting an exploratory study to detect four common machine learning design patterns: Embedding, Multilabel, Feature Cross, and Hashed Feature. We manually label 450 Python code files containing these design patterns from repositories of projects in GitHub. Our approach achieves accuracy values ranging from 80 % to 92% for each of the four patterns.

Abstract The microservices architecture (MSA) style has been gaining interest in recent years because of its high scalability, ability to be deployed in the cloud, and suitability for DevOps practices. While new applications can adopt MSA from their inception, many legacy monolithic systems must be migrated to an MSA to benefit from the advantages of this architectural style. To support the migration process, we propose MicroMiner, a microservices identification approach that is based on static‐relationship analyses between code elements as well as semantic analyses of the source code. Our approach relies on machine learning (ML) techniques and uses service types to guide the identification of microservices from legacy monolithic systems. We evaluate the efficiency of our approach on four systems and compare our results to ground‐truths and to those of two state‐of‐the‐art approaches. We perform a qualitative evaluation of the resulted microservices by analyzing the business capabilities of the identified microservices. Also a quantitative analysis using the state‐of‐the‐art metrics on independence of functionality and modularity of services was conducted. Our results show the effectiveness of our approach to automate one of the most time‐consuming steps in the migration of legacy systems to microservices. The proposed approach identifies architecturally significant microservices with a 68.15% precision and 77% recall.

Typical object-oriented (OO) systems implement several functional features that are interwoven into class hierarchies. In the absence of aspect-oriented techniques to develop and compose these features, developers resort to object-oriented design and programming idioms to separate features as well as possible. Given a legacy OO system, discovering existing functional features helps understand the design of the system and extract these features to ease their maintenance and reuse. We want to discover candidate functional features in OO systems. We first define functional features and then discuss the footprints that such features are likely to leave in an OO system. We identify three such footprints: (1) multiple inheritance, (2) delegation, and (3) ad-hoc. We develop a set of algorithms for identifying such footprints in OO code and implemented them for the Java language using Eclipse JDT. In this article, we present the algorithms, and the results of applying the corresponding tools on five open-source systems: FreeMind, JavaWebMail, JHotDraw, JReversePro, and Lucene. Our experimental results show that: (1) the different algorithms can identify interesting and useful candidate functional features in OO systems, (2) they can identify opportunities for refactoring, and (3) they are complementary and could help developers.

Sentiment analysis in software engineering (SE) has shown promise to analyze and support diverse development activities. Recently, several tools are proposed to detect sentiments in software artifacts. While the tools improve accuracy over off-the-shelf tools, recent research shows that their performance could still be unsatisfactory. A more accurate sentiment detector for SE can help reduce noise in analysis of software scenarios where sentiment analysis is required. Recently, combinations, i.e., hybrids of stand-alone classifiers are found to offer better performance than the stand-alone classifiers for fault detection. However, we are aware of no such approach for sentiment detection for software artifacts. We report the results of an empirical study that we conducted to determine the feasibility of developing an ensemble engine by combining the polarity labels of stand-alone SE-specific sentiment detectors. Our study has two phases. In the first phase, we pick five SE-specific sentiment detection tools from two recently published papers by Lin et al. [ 29 , 30 ], who first reported negative results with stand alone sentiment detectors and then proposed an improved SE-specific sentiment detector, POME [ 29 ]. We report the study results on 17,581 units (sentences/documents) coming from six currently available sentiment benchmarks for software engineering. We find that the existing tools can be complementary to each other in 85-95% of the cases, i.e., one is wrong but another is right. However, a majority voting-based ensemble of those tools fails to improve the accuracy of sentiment detection. We develop Sentisead, a supervised tool by combining the polarity labels and bag of words as features. Sentisead improves the performance (F1-score) of the individual tools by 4% (over Senti4SD [ 5 ]) – 100% (over POME [ 29 ]). The initial development of Sentisead occurred before we observed the use of deep learning models for SE-specific sentiment detection. In particular, recent papers show the superiority of advanced language-based pre-trained transformer models (PTM) over rule-based and shallow learning models. Consequently, in a second phase, we compare and improve Sentisead infrastructure using the PTMs. We find that a Sentisead infrastructure with RoBERTa as the ensemble of the five stand-alone rule-based and shallow learning SE-specific tools from Lin et al. [ 29 , 30 ] offers the best F1-score of 0.805 across the six datasets, while a stand-alone RoBERTa shows an F1-score of 0.801.

Many companies, e.g., Facebook and YouTube, use the REST architecture and provide REST APIs to their clients. Like any other software systems, REST APIs need maintenance and must evolve to improve and stay relevant. Antipatterns—poor design practices—hinder this maintenance and evolution. Although the literature defines many antipatterns and proposes approaches for their (automatic) detection, theircorrectiondid not receive much attention. Therefore,we apply a mixed-method approach to study REST APIs and REST antipatterns with the objectives to recommend corrections or, when possible, actually correct the REST antipatterns.Qualitatively, via case studies, we analyse the evolution of 11 REST APIs, including Facebook, Twitter, and YouTube, over six years. We detect occurrences of eight REST antipatterns in the years 2014, 2017, and 2020 in 17 versions of 11 REST APIs. Thus, we show that (1) REST APIs and antipatterns evolve over time and (2) developers seem to remove antipatterns.Qualitatively via a discourse analysis, we analyse developers’ forums and report that developers are concerned with the occurrences of REST antipatterns and discuss corrections to these antipatterns. Following these qualitative studies, using anengineering-research approach, we propose the following novel and unique contributions: (1) we describe and compare the corrections of eight REST antipatterns from the academic literature and from developers’ forums; (2) we devise and describe algorithms to recommend corrections to some of these antipatterns; (3) we present algorithms and a tool to correct some of these antipatterns by intercepting and modifying responses from REST APIs; and, (4) we validate the recommendations and the corrections manually and via a survey answered by 24 REST developers.Thus, we propose to REST API developers and researchers the first, grounded approach to correct REST antipatterns.

Video-game projects are notorious for having day- one bugs, no matter how big their budget or team size. The quality of a game is essential for its success. This quality could be assessed and ensured through testing. However, to the best of our knowledge, little is known about video-game testing. In this paper, we want to understand how game developers perform game testing. We investigate, through a survey, the academic and gray literature to identify and report on existing testing processes and how they could automate them. We found that game developers rely, almost exclusively, upon manual play-testing and the testers' intrinsic knowledge. We conclude that current testing processes fall short because of their lack of automation, which seems to be the natural next step to improve the quality of games while maintaining costs. However, the current game-testing techniques may not generalize to different types of games.

More and more software projects are being consolidated into ecosystems to increase their discovery, usability, and usefulness. Some of the most popular ecosystems exist in npmjs, Python Package Indexing, and Apache Maven Repository. It is difficult for developers to relate these projects and use them to their full potential because of their number, the spread and depth of their features, and their intrinsic and accidental complexities. We present a technique—SECO Storms Maker—to capture and present the essential information from projects in an ecosystem to help developers join, use, and contribute to the ecosystem. We generate word-clouds based on the projects’ documentation via tokenization and distribution frequency. We identify relations among projects using grammar patterns scanning after part-of-speech tagging. We put these word-clouds into a graph to ease navigation and exploration. We evaluate our technique by manually building a ground truth and comparing a randomly-selected project with SECO to show its benefits.

The Internet of Things (IoT) is a network of physical, connected devices providing services through private networks and the Internet. The devices connect through the Internet to Web servers and other devices. One of the popular programming languages for communicating Web pages and Web apps is JavaScript (JS). Hence, the devices would benefit from JS apps. However, porting JS apps to the many IoT devices, e.g., System-on-a-Chip (SoCs) devices (e.g., Arduino Uno), is challenging because of their limited memory, storage, and CPU capabilities. Also, some devices may lack hardware/software capabilities for running JS apps “as is”. Thus, we proposeMoMIT, a multiobjective optimization approach to miniaturize JS apps to run on IoT devices. We implementMoMITusing three different search algorithms. We miniaturize a JS interpreter and measure the characteristics of 23 apps before/after applyingMoMIT. We find reductions of code size, memory usage, and CPU time of 31, 56, and 36 percent, respectively (medians). We show thatMoMITallows apps to run on up to two additional devices in comparison to the original JS interpreter.

The continuous growth of the mobile apps industry creates a competition among apps developers. To succeed, app developers must attract and retain users. User reviews provide a wealth of information about bugs to fix and features to add and can help app developers offer high-quality apps. However, apps may receive hundreds of unstructured reviews, which makes transforming them into change requests a difficult task. Approaches exist for analyzing and extracting topics from mobile app reviews, however, prioritizing these reviews has not gained much attention. In this study, we introduce the use of a consensus algorithm to help developers prioritize user reviews for the purpose of app evolution. We evaluate the usefulness of our approach and meaningfulness of its consensus rankings on four Android apps. We compare the rankings against reviews ranked by app developers manually and show that there is a strong correlation between the two (average Kendall rank correlation coefficient = 0.516). Thus, our approach can prioritize user reviews and help developers focus their time/effort on improving their apps instead of on identifying reviews to address in the next release.

Different from traditional software development, there is little information about the software-engineering process and techniques in video-game development. One popular way to share knowledge among the video-game developers' community is the publishing of postmortems, which are documents summarizing what happened during the video-game development project. However, these documents are written without formal structure and often providing disparate information. Through this paper, we provide developers and researchers with grounded dataset describing software-engineering problems in video-game development extracted from postmortems. We created the dataset using an iterative method through which we manually coded more than 200 postmortems spanning 20 years (1998 to 2018) and extracted 1,035 problems related to software engineering while maintaining traceability links to the postmortems. We grouped the problems in 20 different types. This dataset is useful to understand the problems faced by developers during video-game development, providing researchers and practitioners a starting point to study video-game development in the context of software engineering.

Software engineering is vital for IoT systems to design systems that are secure, interoperable, modifiable, and scalable. However, industry and academia are still working on many crucial questions related to software engineering for IoT systems, for example, regarding the best practices for developing IoT systems, how to select the hardware, communication, and software architectures of IoT systems, which communications protocols are the most suitable for a system, and how to guarantee security and privacy when dealing with consumer products often composing IoT systems.

Anti-patterns are poor solutions to recurring design problems. Number of empirical studies have highlighted the negative impact of anti-patterns on software maintenance which motivated the development of various detection techniques. Most of these approaches rely on structural metrics of software systems to identify affected components while others exploit historical information by analyzing co-changes occurring between code components. By relying solely on one aspect of software systems (i.e., structural or historical), existing approaches miss some precious information which limits their performances. In this paper, we propose CAME (Convolutional Analysis of code Metrics Evolution), a deep-learning based approach that relies on both structural and historical information to detect anti-patterns. Our approach exploits historical values of structural code metrics mined from version control systems and uses a Convolutional Neural Network classifier to infer the presence of anti-patterns from this information. We experiment our approach for the widely know God Class anti-pattern and evaluate its performances on three software systems. With the results of our study, we show that: (1) using historical values of source code metrics allows to increase the precision; (2) CAME outperforms existing static machine-learning classifiers; and (3) CAME outperforms existing detection tools.

Internet of Things (IoT) aims to bring connectivity to almost every objects, i.e., things, found in the physical space. It extends connectivity to everyday things, however, such increase in the connectivity creates many prominent challenges. Context: Generally, IoT opens the door for new applications for machine-to-machine and human-to-human communications. The current trend of collaborating, distributed teams through the Internet, mobile communications, and autonomous entities, e.g., robots, is the first phase of the IoT to develop and deliver diverse services and applications. However, such collaborations is threatened by the fragmentation that we witness in the industry nowadays as it brings difficulty to integrate the diverse technologies of the various objects found in IoT systems. Diverse technologies induce interoperability issues while designing and developing various services and applications, hence, limiting the possibility of reusing the data, more specifically, the software (including frameworks, firmware, applications programming interfaces, and user interfaces) as well as of facing issues, like security threats and bugs, when developing new services or applications. Different aspects of handling data collection ranging from discovering smart sensors for data collection, integrating and applying reasoning on them must be available to provide interoperability and flexibility to the diverse objects interacting in the system. However, such approaches are bound to be challenged in future IoT scenarios as they bring substantial performance impairments in settings with the very large number of collaborating devices and technologies. Objective: We raise the awareness of the community about the lack of interoperability among technologies developed for IoT and challenges that their integration poses. We also provide guidelines for researchers and practitioners interested in connecting IoT networks and devices to develop services and applications. Method: We apply the methods advocated by the evidence-based software engineering paradigm. This paradigm and its core tool, the systematic literature review (SLR), were introduced to the software-engineering research community early 2004 to help researchers and industry systematically and objectively gather and aggregate evidences about different topics. In this paper, we conduct an SLR of both IoT interoperability issues and the state-of-practice of IoT technologies in the industry, highlighting the integration challenges related to the IoT that have significantly shifted the landscape of Internet-based collaborative services and applications nowadays. Results: Our SLR identifies a number of studies from journals, conferences, and workshops with the highest quality in the field. This SLR reports different trends, including frameworks and technologies, for the IoT for better comprehension of the paradigm and discusses the integration and interoperability challenges across the different layers of this technology while shedding light on the current IoT state-of-practice. It also discusses some future research directions for the community.

Summary This systematic literature review paper investigates the key techniques employed to identify smells in different paradigms of software engineering from object‐oriented (OO) to service‐oriented (SO). In this review, we want to identify commonalities and differences in the identification of smells in OO and SO systems. Our research method relies on an automatic search from the relevant digital libraries to find the studies published since January 2000 on smells until December 2017. We have conducted a pilot and author‐based search that allows us to select the 78 most relevant studies after applying inclusion and exclusion criteria. We evaluated the studies based on the smell detection techniques and the evolution of different methodologies in OO and SO. Among the 78 relevant studies selected, we have identified six different studies in which linguistic source code analysis received less attention from the researchers as compared to the static source code analysis. Smells like the yo‐yo problem, unnamed coupling, intensive coupling, and interface bloat received considerably less attention in the literature. We also identified a catalog of 30 smells infrequently reported for SO systems and that require further attention. Moreover, a suite of 20 smells reported for SO systems can also be detected using static source code metrics in OO. Finally, our review highlighted three major research trends that are further subdivided into 20 research patterns initiating the detection of smells toward their correction.

Service-based Systems (SBSs) are developed on top of diverse Service-Oriented Architecture (SOA) technologies or architectural styles. Like any other complex systems, SBSs face both functional and non-functional changes at the design or implementation-level. Such changes may degrade the design quality and quality of service (QoS) of the services in SBSs by introducing poor solutions-service antipatterns. The presence of service antipatterns in SBSs may hinder the future maintenance and evolution of SBSs. Assessing the quality of design and QoS of SBSs through the detection of service antipatterns may ease their maintenance and evolution. However, the current literature lacks a unified approach for modelling and evaluating the design of SBSs in term of design quality and QoS. To address this lack, this paper presents a meta-model unifying the three main service technologies: REST, SCA, and SOAP. Using the meta-model, it describes a unified approach, UniDoSA (Unified Specification and Detection of Service Antipatterns), supported by a framework, SOFA (Service Oriented Framework for Antipatterns), for modelling and evaluating the design quality and QoS of SBSs. We apply and validate UniDoSA on: (1) 18 RESTful APIs, (2) two SCA systems with more than 150 services, and (3) more than 120 SOAP Web services. With a high precision and recall, the detection results provide evidence of the presence of service antipatterns in SBSs, which calls for future studies of their impact on QoS.

J2EE applications tend to be multi-tier and multi-language applications. They rely on the J2EE platform and containers that offer infrastructure and architectural services to ensure distributed, secure, safe, and scalable executions. These mechanisms hide many program dependencies, which helps development but hinders maintenance, evolution, and re-engineering of J2EE applications. In this paper, we study (i) the J2EE specifications to extract a declarative specification of the dependencies that are inherent in the services offered and that are not visible in the user code that uses them. Then, we introduce (ii) a codification of the dependencies into rules, and (iii) a tool that supports the specification of those dependencies and their detection in J2EE applications. We validate our approach and tool on a sample of 10 J2EE applications. We also compare our tool against JRipples, a state-of-the-art tool for change-impact analysis tasks. Results show that our tool adds, on average, 15% more call dependencies, which would have been missed otherwise. On change impact analysis tasks, our tool outperforms JRipples in all 10 applications, especially for the early iterations of change propagation exploration.

There are two well-known difficulties to test and interpret methodologies for mining developer interaction traces: first, the lack of enough large datasets needed by mining or machine learning approaches to provide reliable results; and second, the lack of "ground truth" or empirical evidence that can be used to triangulate the results, or to verify their accuracy and correctness. Moreover, relying solely on interaction traces limits our ability to take into account contextual factors that can affect the applicability of mining techniques in other contexts, as well hinders our ability to fully understand the mechanics behind observed phenomena. The data presented in this paper attempts to alleviate these challenges by providing 600+ hours of developer interaction traces, from which 26+ hours are backed with video recordings of the IDE screen and developer's comments. This data set is relevant to researchers interested in investigating program comprehension, and those who are developing techniques for interaction traces analysis and mining.

Software engineers are creators of habits. During software development, they follow again and again the same patterns when architecting, designing and implementing programs. Alexander introduced such patterns in architecture in 1974 and, 20 years later, they made their way in software development thanks to the work of Gamma et al. Software design patterns were promoted to make the design of programs more "flexible, modular, reusable, and understandable". However, ten years later, these patterns, their roles, and their impact on software quality were not fully understood. We then set out to study the impact of design patterns on different quality attributes and published a paper entitled "Do Design Patterns Impact Software Quality Positively?" in the proceedings of the 12thEuropean Conference on Software Maintenance and Reengineering (CSMR) in 2008. Ten years later, this paper received the Most Influential Paper award at the 25thInternational Conference on Software Analysis, Evolution, and Reengineering (SANER) in 2018. In this retrospective paper for the award, we report and reflect on our and others' studies on the impact of design patterns, discussing some key findings reported about design patterns. We also take a step back from these studies and re-examine the role that design patterns should play in software development. Finally, we outline some avenues for future research work on design patterns, e.g., the identification of the patterns really used by developers, the theories explaining the impact of patterns, or their use to raise the abstraction level of programming languages.

To support program comprehension, maintenance, and evolution, metamodels are frequently used during program reverse engineering activities to describe and analyze constituents of a program and their relations. Reverse engineering tools often define their own metamodels according to the intended purposes and features. Although each metamodel has its own advantages, its limitations may be addressed by other metamodels. Existing works have evaluated and compared metamodels and tools, but none have considered all the possible characteristics and limitations to provide a comprehensive guideline for classifying, comparing, reusing, and extending program metamodels. To aid practitioners and researchers in classifying, comparing, reusing, and extending program metamodels and their corresponding reverse engineering tools according to the intended goals, we establish a conceptual framework with definitions of program metamodels and related concepts. We confirmed that any reverse engineering activity can be clearly described as a pattern based on the framework from the viewpoint of program metamodels. Then the framework is used to provide a comprehensive taxonomy, named Program Metamodel TAxonomy (ProMeTA), which incorporates newly identified characteristics into those stated in previous works, which were identified via a systematic literature review (SLR) on program metamodels, while keeping the orthogonality of the entire taxonomy. Additionally, we validate the taxonomy in terms of its orthogonality and usefulness through the classification of popular metamodels.

The Android market is a place where developers offer paid and-or free apps to users. Free apps can follow the freemium or the ads-business model. While the former offers less features and the user is charged for unlocking additional features, the latter includes ads to allow developers to get a revenue. Free apps are interesting to users because they can try them immediately without incurring a monetary cost. However, free apps often have limited features and-or contain ads when compared to their paid counterparts. Thus, users may eventually need to pay to get additional features and-or remove ads. While paid apps have clear market values, their ads-supported versions are not entirely free because ads have an impact on performance. The hidden costs of ads, and the recent possibility to form family groups in Google Play to share purchased apps, make it difficult for developers and users to balance between visible and hidden costs of paid and ads-supported apps. In this paper, first, we perform an exploratory study about ads-supported and paid apps to understand their differences in terms of implementation and development process. We analyze 40 Android apps and we observe that (i) ads-supported apps are preferred by users although paid apps have a better rating, (ii) developers do not usually offer a paid app without a corresponding free version, (iii) ads-supported apps usually have more releases and are released more often than their corresponding paid versions, (iv) there is no a clear strategy about the way developers set prices of paid apps, (v) paid apps do not usually include more functionalities than their corresponding ads-supported versions, (vi) developers do not always remove ad networks in paid versions of their ads-supported apps, and (vii) paid apps require less permissions than ads-supported apps. Second, we carry out an experimental study to compare the performance of ads-supported and paid apps and we propose four equations to estimate the cost of ads-supported apps. We obtain that (i) ads-supported apps use more resources than their corresponding paid versions with statistically significant differences and (ii) paid apps could be considered a most cost-effective choice for users because their cost can be amortized in a short period of time, depending on their usage.

Program dependency artifacts such as call graphs help support a number of software engineering tasks such as software mining, program understanding, debugging, feature location, software maintenance and evolution. Java Enterprise Edition (JEE) applications represent a significant part of the recent legacy applications, and we are interested in modernizing them. This modernization involves, among other things, analyzing dependencies between their various components/tiers. JEE applications tend to be multilanguage, rely on JEE container services, and make extensive use of late binding techniques-all of which makes finding such dependencies difficult. In this paper, we describe some of these difficulties and how we addressed them to build a dependency call graph. We developed our tool called DeJEE (Dependencies in JEE) as an Eclipse plug-in. We applied DeJEE on two open-source JEE applications: Java PetStore and JSP Blog. The results show that DeJEE is able to identify different types of JEE dependencies.

A main difficulty to study the evolution and quality of real-life software systems is the effect of moderator factors, such as: programming skill, type of maintenance task, and learning effect. Experimenters must account for moderator factors to identify the relationships between the variables of interest. In practice, controlling for moderator factors in realistic (industrial) settings is expensive and rather difficult. The data presented in this paper has two particularities: First, it involves six professional developers and four real-life, industrial systems. Second, it was obtained from controlled, multiple case studies where the moderator variables: programming skill, maintenance task, and learning effect were controlled for. This data set is relevant to experimenters studying evolution and quality of real-life systems, in particular those interested in studying industrial systems and replicating empirical studies.

Continuous Integration (CI) is a cornerstone of modern quality assurance, providing on-demand builds (compilation and tests) of code changes or software releases. Despite the myriad of CI tools and frameworks, the basic activity of interpreting build results is not straightforward, due to not only the number of builds being performed but also, and especially, due to the phenomenon of build inflation, according to which one code change can be built on dozens of different operating systems, run-time environments and hardware architectures. As existing work mostly ignored this inflation, this paper performs a large-scale empirical study of the impact of OS and run-time environment on build failures on 30 million builds of the CPAN ecosystem's CI environment. We observe the evolution of build failures over time, and investigate the impact of OSes and environments on build failures. We show that distributions may fail differently on different OSes and environments and, thus, that the results of CI require careful filtering and selection to identify reliable failure data.

In software engineering, a smell is a part of a software system's source code with a poor quality and that may indicate a deeper problem. Although many kinds of smells have been studied to analyze their causes, their behavior, and their impact on software quality, those smells typically are studied independently from each other. However, if two smells coincide inside a class, this could increases their negative effect (e.g., spaghetti code that is being cloned across the system). In this paper we report results from an empirical study conducted to examine the relationship between two specific kinds of smells: code clones and antipatterns. We conducted our study on three open-source software systems: Azureus, Eclipse, and JHotDraw. Results show that between 32% and 63% of classes in the analysed systems present co-occurrence of smells, and that such classes are more risky in term of fault-proneness.

One of the most important tasks in software maintenance is debugging. Developers perform debugging to fix faults and implement new features. Usually they use interactive development environments to perform their debugging sessions. To start an interactive debugging session, developers must set breakpoints. Choosing where to set breakpoints is a non-trivial task, yet few studies have investigated how developers set breakpoints during interactive debugging sessions. To understand how developers set breakpoints, we analysed more than 10 hours of 45 video-recorded debugging sessions, where a total of 307 breakpoints were set. We used the videos from two independent studies involving three software systems. We could observe that: (1) considerable time is spent by developers until they are able to set the first breakpoint; (2) when developers toggle breakpoints carefully, they complete tasks faster than developers who set (potential useless) breakpoints quickly; and (3) different developers set breakpoints in similar locations while working (independently) on the same tasks or different tasks. We discuss some implications of our observations for debugging activities.

Identifier lexicon may have a direct impact on software understandability and reusability and, thus, on the quality of the final software product. Understandability and reusability are two important characteristics of software quality. REpresentational State Transfer (REST) style is becoming a de facto standard adopted by software organizations to build their Web applications. Understandable and reusable Uniform Resource Identifers (URIs) are important to attract client developers of RESTful APIs because good URIs support the client developers to understand and reuse the APIs. Consequently, the use of proper lexicon in RESTful APIs has also a direct impact on the quality of Web applications that integrate these APIs. Linguistic antipatterns represent poor practices in the naming, documentation, and choice of identifiers in the APIs as opposed to linguistic patterns that represent the corresponding best practices. In this paper, we present the Semantic Analysis of RESTful APIs (SARA) approach that employs both syntactic and semantic analyses for the detection of linguistic patterns and antipatterns in RESTful APIs. We provide detailed definitions of 12 linguistic patterns and antipatterns and define and apply their detection algorithms on 18 widely-used RESTful APIs, including Facebook, Twitter, and Dropbox. Our detection results show that linguistic patterns and antipatterns do occur in major RESTful APIs in particular in the form of poor documentation practices. Those results also show that SARA can detect linguistic patterns and antipatterns with higher accuracy compared to its state-of-the-art approach — DOLAR.

To support program comprehension, maintenance, and evolution, metamodels are frequently used during program reverse engineering activities to describe and analyze constituents of a program and their relations. Reverse engineering tools often define their own metamodels according to the intended purposes and features. Although each metamodel has its own advantages, its limitations may be addressed by other metamodels. Existing works have evaluated and compared metamodels and tools, but none have considered all the possible characteristics and limitations to provide a comprehensive guideline for classifying, comparing, reusing, and extending program metamodels. To aid practitioners and researchers in classifying, comparing, reusing, and extending program metamodels and their corresponding reverse engineering tools according to the intended goals, we establish a conceptual framework with definitions of program metamodels and related concepts. Then this framework is used to provide a comprehensive taxonomy, named Program Metamodel TAxonomy (ProMeTA), which incorporates newly identified characteristics into those stated in previous works, which were identified via a systematic literature survey on program metamodels, while keeping the orthogonality of the entire taxonomy. Additionally, we validate the taxonomy in terms of its orthogonality and usefulness through the classification of popular metamodels.

Debugging is a laborious activity in which developers spend lot of time navigating through code, looking for starting points, and stepping through statements. In this paper, we present the Swarm Debug Infrastructure (SDI) with which researchers can collect and share data about developers' interactive debugging activities. SDI allows collecting and sharing debugging data that are useful to answer research questions about interactive debugging activities. We assess the effectiveness of the SDI through an experiment to understand how developers apply interactive debugging

Avionics systems, along with their internal hardware and software components interfaces, must be well defined and specified (e.g., unambiguous, complete, verifiable, consistent, and traceable specification). Such a specification is usually written in the form of an Interface Control Document (ICD), and represents the cornerstone of the avionics system integration activities. However, there is no commonly accepted language to define and use these ICDs and no common definition of what an ICD is or should contain. Indeed, avionics companies define their own, proprietary ICDs and processes. In this paper, we first identify the pieces of information that an ICD should contain for both federated and IMA open systems. Then, we propose a data extraction process that enables better understanding and more efficient extraction of open avionics systems interface specifications, and provides a clearer vision on the information needed to build a model driven solution for modeling avionics system interfaces, our long-term goal. We validate this process by applying it on a set of open avionics sub-system standards and the results have shown its feasibility.

Debugging is a laborious activity in which developers spend lot of time navigating through code, looking for starting points, and stepping through statements. Yet, although debuggers exist for 40 years now, there have been few research studies to understand this important and laborious activity. Indeed, to perform such a study, researchers need detailed information about the different steps of the interactive debugging process. In this paper, to help research studies on debugging and, thus, help improving our understanding of how developers debug systems using debuggers, we present the Swarm Debug Infrastructure (SDI), with which practitioners and researchers can collect and share data about developers' interactive debugging activities. We assess the effectiveness of the SDI through an experiment that aims to understand how developers apply interactive debugging on five true faults found in JabRef, toggling breakpoints and stepping code. Our study involved five freelancers and two student developers performing 19 bug location sessions. We collect videos recording and data about 6 hours of effective debugging activities. The data includes 110 breakpoints and near 7,000 invocations. We process the collected videos and data to answer five research questions showing that (1) there is no correlation between the number of invocations (respectively the number of breakpoints toggled) during a debugging session and the time spent on the debugging task, ρ = -0.039 (respectively 0.093). We also observed that (2) developers follow different debugging patterns and (3) there is no relation between numbers of breakpoints and expertise. However, (4) there is a strong negative correlation between time of the first breakpoint (ρ = -0.637), and the time spent on the task, suggesting that when developers toggle breakpoints carefully, they complete tasks faster than developers who toggle breakpoints too quickly. We conclude that the SDI allows collecting and sharing debugging data that can provide interesting insights about interactive debugging activities. We discuss some implications for tool developers and future debuggers.

There exists a large body of work on the specification and detection of anti-patterns in the source code of software systems. However, there are very few studies on the origins of the occurrences of anti-patterns in the source code: do the very design of the systems lead to the occurrences of anti-patterns or are anti-patterns introduced during implementation? Knowing when anti-patterns are introduced could help software designers and developers improve the quality of the source code, for example by eliminating fault-prone anti-patterns early during the design of the systems, even before their implementation. Therefore, we detect occurrences of anti-patterns in design models and in the source code of some systems, trace these occurrences between design and implementation, and study their relation and impact on the source code. First, we analyze both the UML design models and the source code of 10 open-source systems and show that antipatterns exist in design models. We observe that, on average, 37% of the classes in the design models that belong to anti-patterns also exist in the source code and also play roles in the same anti-patterns. Second, we investigate two open-source systems to assess the impact of the anti-patterns in their design models on the source code in terms of changes and faults. We show that classes that have anti-patterns in the design models have more changes and faults in the source code. Our results suggest that the design of the systems lead to anti-patterns and that the antipatterns impact negatively the change-and fault-proneness of the classes in the source code. Thus, designers should be wary of anti-patterns in their design models and could benefit from tools that detect and trace these anti-patterns into the source code.

Empirical studies have shown so far that code smells have relatively low impact over maintenance effort at file level. We surmise that previous studies have found low effects of code smells because the effort considered is a "sheer-effort" that does not distinguish between the kinds of developers' activities. In our study, we investigate the effects of code smells at the activity level. Examples of activities are: reading, editing, searching, and navigating, which are performed independently over different files during maintenance. We conjecture that structural attributes represented in the form of different code smells do indeed have an effect on the effort for performing certain kinds of activities. To verify this conjecture, we revisit a previous study about the impact of code smell on maintenance effort, using the same dataset, but considering activity effort. Six professional developers were hired to perform three maintenance tasks on four functionally equivalent Java Systems. Each developer performs two maintenance tasks. During maintenance task, we monitor developers' logs. Then, we define an annotation schema to identify developers' activities and assess whether code smells affect different maintenance activities. Results show that different code smells affect differently activity effort. Yet, the size of the changes performed to solve the task impacts the effort of all activities more than code smells and file size. While code smells impact the editing and navigating effort more than file size, the file size impacts the reading and searching activities more than code smells. One major implication of these results is that if code smells indeed affect the effort of certain kinds of activities, it means that their effects are contingent on the type of maintenance task at hand, where some kinds of activities will become more predominant than others.

Abstract Several techniques are used by requirements engineering practitioners to address difficult problems such as specifying precise requirements while using inherently ambiguous natural language text and ensuring the consistency of requirements. Often, these problems are addressed by building processes/tools that combine multiple techniques where the output from 1 technique becomes the input to the next. While powerful, these techniques are not without problems. Inherent errors in each technique may leak into the subsequent step of the process. We model and study 1 such process, for checking the consistency of temporal requirements, and assess error leakage and wasted time. We perform an analysis of the input factors of our model to determine the effect that sources of uncertainty may have on the final accuracy of the consistency checking process. Convinced that error leakage exists and negatively impacts the results of the overall consistency checking process, we perform a second simulation to assess its impact on the analysts' efforts to check requirements consistency. We show that analyst's effort varies depending on the precision and recall of the subprocesses and that the number and capability of analysts affect their effort. We share insights gained and discuss applicability to other processes built of piped techniques.

Eye-tracking studies are getting more prevalent in software engineering. Researchers often use different metrics when publishing their results in eye-tracking studies. Even when the same metrics are used, they are given different names, causing difficulties in comparing studies. To encourage replications and facilitate advancing the state of the art, it is important that the metrics used by researchers be clearly and consistently defined in the literature. There is therefore a need for a survey of eye-tracking metrics to support the (future) goal of standardizing eye-tracking metrics. This paper seeks to bring awareness to the use of different metrics along with practical suggestions on using them. It compares and contrasts various eye-tracking metrics used in software engineering. It also provides definitions for common metrics and discusses some metrics that the software engineering community might borrow from other fields.

Context: Developers' interaction traces (ITs) are commonly used in software engineering to understand how developers maintain and evolve software systems. Researchers make several assumptions when mining ITs, e.g., edit events are considered to be change activities and the time mined from ITs is considered to be the time spent by the developers performing the maintenance task. Goal: We investigate the extent to which these assumptions are correct. We examine noises in developers'''' ITs data and the impact of these noises on previous results derived from these traces. Approach: We perform an experiment with 15 participants, whom we asked to perform bug-fixing activities and collect Mylyn ITs and VLC video captures. We then investigate noises between the two data sets and propose an approach to correct noises in ITs. Results: We find that Mylyn ITs can miss on average about 6% of the time spent performing a task and contain on average about 28% of false edit-events. We report that these noises may have led researchers to mislabel some participants'''' editing styles in about 34% of the cases and that the numbers of edit-events performed by developers and the times that they spent on tasks are correlated, when they were considered not to be. Conclusion: We show that ITs must be carefully cleaned before being used in research studies.

Cloud Patterns are abstract solutions to recurrent design problems in the cloud. Previous work has shown that these patterns can improve the Quality of Service (QoS) of cloud applications but their impact on energy consumption is still unknown. Yet, energy consumption is the biggest challenge that cloud computing systems (the backbone of today's high-tech economy) face today. In fact, 10% of the world's electricity is now being consumed by servers, laptops, tablets and smartphones. Energy consumption has complex dependencies on the hardware platform, and the multiple software layers. The hardware, its firmware, the operating system, and the various software components used by a cloud application, all contribute to determining the energy footprint. Hence, even though increasing a data center efficiency will eventually improve energy efficiency, the internal design of cloud-based applications can be improved to lower energy consumption. In this paper, we conduct an empirical study on a RESTful multi-threaded application deployed in the cloud, to investigate the individual and the combined impact of three cloud patterns (e.g., Local Database proxy, Local Sharding Based Router and Priority Queue) on the energy consumption of cloud based applications. We measure the energy consumption using Power-API; an application programming interface (API) written in Java to monitor the energy consumed at the process-level. Results show that cloud patterns can effectively reduce the energy consumption of a cloud application, but not in all cases. In general, there appear to be a trade-off between an improved response time of the application and the energy consumption. Developers and software architects can make use of these results to guide their design decisions.

This paper describes ongoing work to characterize the inherent ease or “traceability” with which a textual artifact can be traced using an automated technique. Software traceability approaches use varied measures to build models that automatically recover links between pairs of natural language documents. Thus far, most of the approaches use a single-step model, such as logistic regression, to identify new trace links. However, such approaches require a large enough training set of both true and false trace links. Yet, the former are by far in the minority, which reduces the performance of such models. Therefore, this paper formulates the problem of identifying trace links as the problem of finding, for a given logistic regression model, the subsets of links in the training set giving the best accuracy (in terms of G-metric) on a test set. Using hill climbing with random restart for subset selection, we found that, for the ChangeStyle dataset, we can classify links with a precision of up to 40% and a recall of up to 66% using a training set as small as one true candidate link (out of 33) and 41 false links. To get better performance and learn the best possible logistic regression classifier, we must “discard” links in the trace dataset that increase noise to avoid learning with links that are not representative. This preliminary work is promising because it shows that few correct examples may perform better than several poor ones. It also shows which inherent characteristics of the artifacts make them good candidates to learn efficient traceability models automatically, i.e., it reveals their traceability.

Search-based approaches have been extensively applied to solve the problem of software test-data generation. Yet, test-data generation for object-oriented programming (OOP) is challenging due to the features of OOP, e.g., abstraction, encapsulation, and visibility that prevent direct access to some parts of the source code. To address this problem we present a new automated search-based software test-data generation approach that achieves high code coverage for unit-class testing. We first describe how we structure the test-data generation problem for unit-class testing to generate relevant sequences of method calls. Through a static analysis, we consider only methods or constructors changing the state of the class-under-test or that may reach a test target. Then we introduce a generator of instances of classes that is based on a family of means-of-instantiation including subclasses and external factory methods. It also uses a seeding strategy and a diversification strategy to increase the likelihood to reach a test target. Using a search heuristic to reach all test targets at the same time, we implement our approach in a tool, JTExpert, that we evaluate on more than a hundred Java classes from different open-source libraries. JTExpert gives better results in terms of search time and code coverage than the state of the art, EvoSuite, which uses traditional techniques.

Some previous work began studying the relationship between application domains and quality, in particular through the prevalence of code and design smells (e.g., anti-patterns). Indeed, it is generally believed that the presence of these smells degrades quality but also that their prevalence varies across domains. Though anecdotal experiences and empirical evidence gathered from developers and researchers support this belief, there is still a need to further deepen our understanding of the relationship between application domains and quality. Consequently, we present a large-scale study that investigated the systematic relationships between the presence of smells and quality-related metrics computed over the bytecode of 1,343 Java Mobile Edition applications in 13 different application domains. Although, we did not find evidence of a correlation between smells and quality- related metrics, we found (1) that larger differences exist between metric values of classes exhibiting smells and classes without smells and (2) that some smells are commonly present in all the domains while others are most prevalent in certain domains

Modern software uses frameworks through their Application Programming Interfaces (APIs). Framework APIs may change while frameworks evolve. Client programs have to upgrade to new releases of frameworks if security vulnerabilities are discovered in the used releases. Patching security vulnerabilities can be delayed by non-security-related API changes when the frameworks used by client programs are not up to date. Keeping frameworks updated can reduce the reaction time to patch security leaks. Client program upgrades are not cost free, developers need to understand the API usages in client programs and API changes between framework releases before conduct upgrading tasks. In this paper, we propose a tool ACUA to generate reports containing detailed API change and usage information by analyzing the binary code of both frameworks and clients programs written in Java. Developers can use the API change and usage reports generated by ACUA to estimate the work load and decide when to starting upgrading client programs based on the estimation.

SUMMARY Software maintenance accounts for the largest part of the costs of any program. During maintenance activities, developers implement changes (sometimes simultaneously) on artifacts in order to fix bugs and to implement new requirements. To reduce this part of the costs, previous work proposed approaches to identify the artifacts of programs that change together. These approaches analyze historical data, mined from version control systems, and report change patterns, which lead at the causes, consequences, and actors of the changes to source code files. They also introduce so‐called change patterns that describe some typical change dependencies among files. In this paper, we introduce two novel change patterns: the asynchrony change pattern, corresponding to macro co‐changes (MC), that is, of files that co‐change within a large time interval (change periods) and the dephase change pattern, corresponding to dephase macro co‐changes (DC), that is, MC that always happens with the same shifts in time. We present our approach, that we named Macocha, to identify these two change patterns in large programs. We use the k‐nearest neighbor algorithm to group changes into change periods. We also use the Hamming distance to detect approximate occurrences of MC and DC. We apply Macocha and compare its performance in terms of precision and recall with UMLDiff (file stability) and association rules (co‐changing files) on seven systems: ArgoUML, FreeBSD, JFreeChart, Openser, SIP, XalanC, and XercesC developed with three different languages (C, C++, and Java). These systems have a size ranging from 532 to 1693 files, and during the study period, they have undergone 1555 to 23,944 change commits. We use external information and static analysis to validate (approximate) MC and DC found by Macocha. Through our case study, we show the existence and usefulness of these novel change patterns to ease software maintenance and, potentially, reduce related costs. Copyright © 2013 John Wiley & Sons, Ltd.

ABSTRACT Program comprehension is a prerequisite to any maintenance and evolution task. In particular, when performing feature location, developers perform program comprehension by abstracting software features and identifying the links between high‐level abstractions (features) and program elements. We present Segment Concept AssigNer (SCAN), an approach to support developers in feature location. SCAN uses a search‐based approach to split execution traces into cohesive segments. Then, it labels the segments with relevant keywords and, finally, uses formal concept analysis to identify relations among segments. In a first study, we evaluate the performances of SCAN on six Java programs by 31 participants. We report an average precision of 69% and a recall of 63% when comparing the manual and automatic labels and a precision of 63% regarding the relations among segments identified by SCAN. After that, we evaluate the usefulness of SCAN for the purpose of feature location on two Java programs. We provide evidence that SCAN (i) identifies 69% of the gold set methods and (ii) is effective in reducing the quantity of information that developers must process to locate features—reducing the number of methods to understand by an average of 43% compared to the entire execution traces. Copyright © 2014 John Wiley & Sons, Ltd.

Source code lexicon plays a paramount role in software quality: poor lexicon can lead to poor comprehensibility and even increase software fault-proneness. For this reason, renaming a program entity, i.e., altering the entity identifier, is an important activity during software evolution. Developers rename when they feel that the name of an entity is not (anymore) consistent with its functionality, or when such a name may be misleading. A survey that we performed with 71 developers suggests that 39 percent perform renaming from a few times per week to almost every day and that 92 percent of the participants consider that renaming is not straightforward. However, despite the cost that is associated with renaming, renamings are seldom if ever documented-for example, less than 1 percent of the renamings in the five programs that we studied. This explains why participants largely agree on the usefulness of automatically documenting renamings. In this paper we propose REanaming Program ENTities (REPENT), an approach to automatically document-detect and classify-identifier renamings in source code. REPENT detects renamings based on a combination of source code differencing and data flow analyses. Using a set of natural language tools, REPENT classifies renamings into the different dimensions of a taxonomy that we defined. Using the documented renamings, developers will be able to, for example, look up methods that are part of the public API (as they impact client applications), or look for inconsistencies between the name and the implementation of an entity that underwent a high risk renaming (e.g., towards the opposite meaning). We evaluate the accuracy and completeness of REPENT on the evolution history of five open-source Java programs. The study indicates a precision of 88 percent and a recall of 92 percent. In addition, we report an exploratory study investigating and discussing how identifiers are renamed in the five programs, according to our taxonomy.

Graphical representations are used to visualise, specify, and document software artifacts in all stages of software development process. In contrast with text, graphical representations are presented in two-dimensional form, which seems easy to process. However, few empirical studies investigated the efficiency of graphical representations vs. textual ones in modelling and presenting software requirements. Therefore, in this paper, we report the results of an eye-tracking experiment involving 28 participants to study the impact of structured textual vs. graphical representations on subjects' efficiency while performing requirement comprehension tasks. We measure subjects' efficiency in terms of the percentage of correct answers (accuracy) and of the time and effort spend to perform the tasks. We observe no statistically-significant difference in term of accuracy. However, our subjects spent more time and effort while working with the graphical representation although this extra time and effort does not affect accuracy. Our findings challenge the general assumption that graphical representations are more efficient than the textual ones at least in the case of developers not familiar with the graphical representation. Indeed, our results emphasise that training can significantly improve the efficiency of our subjects working with graphical representations. Moreover, by comparing the visual paths of our subjects, we observe that the spatial structure of the graphical representation leads our subjects to follow two different strategies (top-down vs. bottomup) and subsequently this hierarchical structure helps developers to ease the difficulty of model comprehension tasks.

Like any other large and complex software systems, Service-Based Systems (SBSs) must evolve to fit new user requirements and execution contexts. The changes resulting from the evolution of SBSs may degrade their design and quality of service (QoS) and may often cause the appearance of common poor solutions in their architecture, called antipatterns, in opposition to design patterns, which are good solutions to recurring problems. Antipatterns resulting from these changes may hinder the future maintenance and evolution of SBSs. The detection of antipatterns is thus crucial to assess the design and QoS of SBSs and facilitate their maintenance and evolution. However, methods and techniques for the detection of antipatterns in SBSs are still in their infancy despite their importance. In this paper, we introduce a novel and innovative approach supported by a framework for specifying and detecting antipatterns in SBSs. Using our approach, we specify 10 well-known and common antipatterns, including Multi Service and Tiny Service, and automatically generate their detection algorithms. We apply and validate the detection algorithms in terms of precision and recall two systems developed independently, (1) Home-Automation, an SBS with 13 services, and (2) FraSCAti, an open-source implementation of the Service Component Architecture (SCA) standard with more than 100 services. This validation demonstrates that our approach enables the specification and detection of Service Oriented Architecture (SOA) antipatterns with an average precision of 90% and recall of 97.5%.

SUMMARY The software engineering literature reports empirical evidence on the relation between various characteristics of a software system and its quality. Among other factors, recent studies have shown that a proper choice of identifiers influences understandability and maintainability. Indeed, identifiers are developers' main source of information and guide their cognitive processes during program comprehension when high‐level documentation is scarce or outdated and when source code is not sufficiently commented. This paper proposes a novel approach to recognize words composing source code identifiers. The approach is based on an adaptation of Dynamic Time Warping used to recognize words in continuous speech. The approach overcomes the limitations of existing identifier‐splitting approaches when naming conventions (e.g., Camel Case) are not used or when identifiers contain abbreviations. We apply the approach on a sample of more than 1000 identifiers extracted from 340 C programs and compare its results with a simple Camel Case splitter and with an implementation of an alternative identifier splitting approach, Samurai. Results indicate the capability of the novel approach: (i) to outperform the alternative ones, when using a dictionary augmented with domain knowledge or a contextual dictionary and (ii) to expand 48% of a set of selected abbreviations into dictionary words. Copyright © 2011 John Wiley & Sons, Ltd.

SUMMARY Analyzing and understanding the evolution of large object‐oriented software systems is an important but difficult task in which matching algorithms play a fundamental role. An error‐tolerant graph matching (ETGM) algorithm can identify evolving classes that maintain a stable structure of relations (associations, inheritances, and aggregations) with other classes and thus likely constitute the backbone of the system. Therefore, to study the evolution of class diagrams, we first develop a novel ETGM algorithm, which improves the performance of our previous algorithm. Second, we describe the process of building an oracle to validate the results of our approach to solve the class diagram evolution problem. Third, we report for the new algorithm the impact of its parameters on the F‐measure summarizing precision (quantifying the exactness of the solution) and recall (quantifying the completeness of the solution). Finally, with tuned parameters, we carry out and report an extensive empirical evaluation of our algorithm using small (Rhino), medium (Azureus and ArgoUML), and large systems (Mozilla and Eclipse). We thus show that this novel algorithm is scalable, stable and has better time performance than its earlier version. Copyright © 2010 John Wiley & Sons, Ltd.

Traceability is the only means to ensure that the source code of a system is consistent with its requirements and that all and only the specified requirements have been implemented by developers. During software maintenance and evolution, requirement traceability links become obsolete because developers do not/cannot devote effort to updating them. Yet, recovering these traceability links later is a daunting and costly task for developers. Consequently, the literature has proposed methods, techniques, and tools to recover these traceability links semi-automatically or automatically. Among the proposed techniques, the literature showed that information retrieval (IR) techniques can automatically recover traceability links between free-text requirements and source code. However, IR techniques lack accuracy (precision and recall). In this paper, we show that mining software repositories and combining mined results with IR techniques can improve the accuracy (precision and recall) of IR techniques and we propose Trustrace, a trust--based traceability recovery approach. We apply Trustrace on four medium-size open-source systems to compare the accuracy of its traceability links with those recovered using state-of-the-art IR techniques from the literature, based on the Vector Space Model and Jensen-Shannon model. The results of Trustrace are up to 22.7 percent more precise and have 7.66 percent better recall values than those of the other techniques, on average. We thus show that mining software repositories and combining the mined data with existing results from IR techniques improves the precision and recall of requirement traceability links.

Matching algorithms play a fundamental role in many important but difficult software engineering activities, especially design evolution analysis and model comparison. We present MADMatch, a fast and scalable many-to-many approximate diagram matching approach based on an error-tolerant graph matching (ETGM) formulation. Diagrams are represented as graphs, costs are assigned to possible differences between two given graphs, and the goal is to retrieve the cheapest matching. We address the resulting optimization problem with a tabu search enhanced by the novel use of lexical and structural information. Through several case studies with different types of diagrams and tasks, we show that our generic approach obtains better results than dedicated state-of-the-art algorithms, such as AURA, PLTSDiff, or UMLDiff, on the exact same datasets used to introduce (and evaluate) these algorithms.

Acquiring the skills to plan and conduct different kinds of empirical studies is a mandatory requirement for graduate students working in the field of software engineering. These skills typically can only be developed based on the teaching and experience of the students' supervisor, because of the lack of specific, practical courses providing these skills. To fill this gap, we organized the first Canadian Summer School on Practical Analyses of Software Engineering Data (PASED). The aim of PASED is to provide — using a “learning by doing” model of teaching — a solid foundation to software engineering graduate students on conducting empirical studies. This paper describes our experience in organizing the PASED school, i.e., what challenges we encountered, how we designed the lectures and laboratories, and what could be improved in the future based on the participants' feedback.

Requirements traceability (RT) links help developers to understand programs and ensure that their source code is consistent with its documentation. Creating RT links is a laborious and resource-consuming task. Information Retrieval (IR) techniques are useful to automatically recover traceability links. However, IR-based approaches typically have low accuracy (precision and recall) and, thus, creating RT links remains a human intensive process. We conjecture that understanding how developers verify RT links could help improve the accuracy of IR-based approaches to recover RT links. Consequently, we perform an empirical study consisting of two controlled experiments. First, we use an eye-tracking system to capture developers' eye movements while they verify RT links. We analyse the obtained data to identify and rank developers' preferred source code entities (SCEs), e.g., class names, method names. Second, we use the ranked SCEs to propose two new weighting schemes called SE/IDF (source code entity/inverse document frequency) and DOI/IDF (domain or implementation/inverse document frequency) to recover RT links combined with an IR technique. SE/IDF is based on the developers preferred SCEs to verify RT links. DOI/IDF is an extension of SE/IDF distinguishing domain and implementation concepts. We use LSI combined with SE/IDF, DOI/IDF, and TF/IDF to show, using two systems, iTrust and Pooka, that LSIDOI/IDFstatistically improves the accuracy of the recovered RT links over LSITF/IDF.

Program comprehension is preliminary to any program evolution task. Researchers agree that identifiers play an important role in code reading and program understanding activities. Yet, to the best of our knowledge, only one work investigated the impact of gender on the memorability of identifiers and thus, ultimately, on program comprehension. This paper reports the results of an experiment involving 15 male subjects and nine female subjects to study the impact of gender on the subjects' visual effort, required time, as well as accuracy to recall Camel Case versus Underscore identifiers in source code reading. We observe no statistically-significant difference in term of accuracy, required time, and effort. However, our data supports the conjecture that male and female subjects follow different comprehension strategies: female subjects seem to carefully weight all options and spend more time to rule out wrong answers while male subjects seem to quickly set their minds on some answers, possibly the wrong ones. Indeed, we found that the effort spent on wrong answers is significantly higher for female subjects and that there is an interaction between the effort that female subjects invested on wrong answers and their higher percentages of correct answers when compared to male subjects.

Professional experience is one of the most important criteria for almost any job offer in software engineering. Professional experience refers both to professional status (practitioner vs. student) and expertise (expert vs. novice). We perform an experiment with 21 subjects including both practitioners and students, and experts and novices. We seek to understand the relation between the speed and accuracy of the subjects and their status and expertise in performing maintenance tasks on UML class diagrams. We also study the impact of the formulation of the maintenance task. We use an eye-tracking system to gather the fixations of the subjects when performing the task. We measure the subjects' comprehension using their accuracy, the time spent, the search effort, the overall effort, and the question comprehension effort. We found that (1) practitioners are more accurate than students while students spend around 35 percent less time than practitioners, (2) experts are more accurate than novices while novices spending around 33 percent less time than experts, (3) expertise is the most important factor for accuracy and speed, (4) experienced students are more accurate and spend around 37 percent less time than experienced practitioners, and (5) when the description of the task is precise, the novice students can be accurate. We conclude that it is an illusion for project managers to focus on status only when recruiting a software engineer. Our result is the starting point to consider the differences between status and expertise when studying software engineers' productivity. Thus, it can help project managers to recruit productive engineers and motivated students to acquire the experience and ability in the projects.

Developers may introduce anti-patterns in their software systems because of time pressure, lack of understanding, communication, and--or skills. Anti-patterns impede development and maintenance activities by making the source code more difficult to understand. Detecting anti-patterns in a whole software system may be infeasible because of the required parsing time and of the subsequent needed manual validation. Detecting anti-patterns on subsets of a system could reduce costs, effort, and resources. Researchers have proposed approaches to detect occurrences of anti-patterns but these approaches have currently some limitations: they require extensive knowledge of anti-patterns, they have limited precision and recall, and they cannot be applied on subsets of systems. To overcome these limitations, we introduce SVMDetect, a novel approach to detect anti-patterns, based on a machine learning technique---support vector machines. Indeed, through an empirical study involving three subject systems and four anti-patterns, we showed that the accuracy of SVMDetect is greater than of DETEX when detecting anti-patterns occurrences on a set of classes. Concerning, the whole system, SVMDetect is able to find more anti-patterns occurrences than DETEX.

Bug location assists developers in locating culprit source code that must be modified to fix a bug. Done manually, it requires intensive search activities with unpredictable costs of effort and time. Information retrieval (IR) techniques have been proven useful to speedup bug location in object-oriented programs. IR techniques compute the textual similarities between a bug report and the source code to provide a list of potential culprit classes to developers. They rank the list of classes in descending order of the likelihood of the classes to be related to the bug report. However, due to the low textual similarity between source code and bug reports, IR techniques may put a culprit class at the end of a ranked list, which forces developers to manually verify all non-culprit classes before finding the actual culprit class. Thus, even with IR techniques, developers are not saved from manual effort. In this paper, we conjecture that binary class relationships (BCRs) could improve the rankings by IR techniques of classes and, thus, help reducing developers' manual effort. We present an approach, LIBCROOS, that combines the results of any IR technique with BCRs gathered through source code analyses. We perform an empirical study on four programs -- Jabref, Lucene, muCommander, and Rhino -- to compare the accuracy, in terms of ranking, of LIBCROOS with two IR techniques: latent semantic indexing (LSI) and vector space model (VSM). The results of this empirical study show that LIBCROOS improves the rankings of both IR technique statistically when compared to LSI and VSM alone and, thus, may reduce the developers' effort.

Smart phones, gaming consoles, and wireless routers are ubiquitous; the increasing diffusion of such devices with limited resources, together with society's unsatiated appetite for new applications, pushes companies to miniaturize their programs. Miniaturizing a program for a hand-held device is a time-consuming task often requiring complex decisions. Companies must accommodate conflicting constraints: customers' satisfaction with features may be in conflict with a device's limited storage, memory, or battery life. This paper proposes a process, MoMS, for the multi-objective miniaturization of software to help developers miniaturize programs while satisfying multiple conflicting constraints. It can be used to support the reverse engineering, next release problem, and porting of both software and product lines. The process directs the elicitation of customer pre-requirements, their mapping to program features, and the selection of the features to port. We present two case studies based on Pooka, an email client, and SIP Communicator, an instant messenger, to demonstrate that MoMS supports optimized miniaturization and helps reduce effort by 77%, on average, over a manual approach.

Change impact analysis aims at identifying software artefacts that are being affected by a change. It helps developers to assess their change efforts and perform more adequate changes. Several approaches have been proposed to aid in impact analysis. However, to the best of our knowledge, none of these approaches have been used to study the scope of changes in a program. We present a metaphor inspired by seismology and propose a mapping between the concepts of seismology and change propagation, to study the scope of change propagation. We perform three case studies on Pooka, Rhino, and Xerces-J to observe change propagation. We use ANOVA and Duncan statistical tests to assess the statistically significance of our observations, which show that changes propagate to a limited scope.

Information retrieval (IR) approaches have proven useful in recovering traceability links between free text documentation and source code. IR-based traceability recovery approaches produce ranked lists of traceability links between pieces of documentation and source code. These traceability links are then pruned using various strategies and, finally, validated by human experts. In this paper we propose two contributions to improve the precision and recall of traceability links and, thus, reduces the required human experts' manual validation effort. First, we propose a novel approach, Trustrace, inspired by Web trust models to improve the precision and recall of traceability links: Trustrace uses any traceability recovery approach to obtain a set of traceability links, which rankings are then re-evaluated using a set of other traceability recovery approaches. Second, we propose a novel traceability recovery approach, Histrace, to identify traceability links between requirements and source code through CVS/SVN change logs using a Vector Space Model (VSM). We combine a traditional recovery traceability approach with Histrace to build TrustraceVSM, Histracein which we use Histrace as one expert adding knowledge to the traceability links extracted from CVS/SVN change logs. We apply TrustraceVSM, Histraceon two case studies to compare its traceability links with those recovered using only the VSM-based approach, in terms of precision and recall. We show that TrustraceVSM, Histraceimproves with statistical significance the precision of the traceability links while also improving recall but without statistical significance.

Impact analysis is crucial to make decisions among different alternative implementations and to anticipate future maintenance tasks. Several approaches were proposed to identify software artefacts being affected by a change. However, to the best of our knowledge, none of these approaches have been used to study the scope of changes in a program. Yet, this information would help developers assess their change efforts and perform more adequate changes. Thus, we present a metaphor inspired by seismology and propose a mapping between the concepts of seismology and software evolution. We show the applicability and usefulness of our metaphor using Rhino and Xerces-J.

Identifiers play an important role in source code understandability, maintainability, and fault-proneness. This paper reports a study of identifier renamings in software systems, studying how terms (identifier atomic components) change in source code identifiers. Specifically, the paper (i) proposes a term renaming taxonomy, (ii) presents an approximate lightweight code analysis approach to detect and classify term renamings automatically into the taxonomy dimensions, and (iii) reports an exploratory study of term renamings in two open-source systems, Eclipse-JDT and Tomcat. We thus report evidence that not only synonyms are involved in renamings but also (in a small fraction) more unexpected changes occur: surprisingly, we detected hypernym (a more abstract term, e.g., size vs. length) and hyponym (a more concrete term, e.g., restriction vs. rule) renamings, and antonym renamings (a term replaced with one having the opposite meaning, e.g., closing vs. opening). Despite being only a fraction of all renamings, synonym, hyponym, hypernym, and antonym renamings may hint at some program understanding issues and, thus, could be used in a renamingrecommendation system to improve code quality.

Free and open source software systems (FOSS) are distributed and made available to users under different software licenses, mentioned in FOSS code by means of licensing statements. Various factors, such as changes in the legal landscape, commercial code licensed as FOSS, or code reused from other FOSS systems, lead to evolution of licensing, which may affect the way a system or part thereof can be subsequently used. Therefore, it is crucial to monitor licensing evolution. However, manually tracking the licensing evolution of thousands of files is a daunting task.

Software frameworks and libraries are indispensable to today's software systems. As they evolve, it is often time-consuming for developers to keep their code up-to-date, so approaches have been proposed to facilitate this. Usually, these approaches cannot automatically identify change rules for one-replaced-by-many and many-replaced-by-one methods, and they trade off recall for higher precision using one or more experimentally-evaluated thresholds. We introduce AURA, a novel hybrid approach that combines call dependency and text similarity analyses to overcome these limitations. We implement it in a Java system and compare it on five frameworks with three previous approaches by Dagenais and Robillard, M. Kim et al., and Schafer et al. The comparison shows that, on average, the recall of AURA is 53.07% higher while its precision is similar, e.g., 0.10% lower.

Poorly-chosen identifiers have been reported in the literature as misleading and increasing the program comprehension effort. Identifiers are composed of terms, which can be dictionary words, acronyms, contractions, or simple strings. We conjecture that the use of identical terms in different contexts may increase the risk of faults. We investigate our conjecture using a measure combining term entropy and term context coverage to study whether certain terms increase the odds ratios of methods to be fault-prone. Entropy measures the physical dispersion of terms in a program: the higher the entropy, the more scattered across the program the terms. Context coverage measures the conceptual dispersion of terms: the higher their context coverage, the more unrelated the methods using them. We compute term entropy and context coverage of terms extracted from identifiers in Rhino 1.4R3 and ArgoUML 0.16. We show statistically that methods containing terms with high entropy and context coverage are more fault-prone than others.

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.

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

Abstract Design patterns offer design motifs, solutions to object‐oriented design problems. Design motifs lead to well‐structured designs and thus are believed to ease software maintenance. However, after use, they are often ‘lost’ and are consequently of little help during program comprehension and other maintenance activities. Therefore, several works proposed design pattern identification approaches to recover occurrences of the motifs. These approaches mainly used the structure and organization of classes as input. Consequently, they have a low precision when considering behavioural and creational motifs, which pertain to the assignment of responsibilities and the collaborations among objects at runtime. We propose MoDeC, an approach to describe behavioural and creational motifs as collaborations among objects in the form of scenario diagrams. We identify these motifs using dynamic analysis and constraint programming. Using a proof‐of‐concept implementation of MoDeC and different scenarios for five other Java programs andBuilder,Command, andVisitor, we show that MoDeC has a better precision than the state‐of‐the‐art static approaches. Copyright © 2009 John Wiley & Sons, Ltd.

Code and design smells are poor solutions to recurring implementation and design problems. They may hinder the evolution of a system by making it hard for software engineers to carry out changes. We propose three contributions to the research field related to code and design smells: (1) DECOR, a method that embodies and defines all the steps necessary for the specification and detection of code and design smells, (2) DETEX, a detection technique that instantiates this method, and (3) an empirical validation in terms of precision and recall of DETEX. The originality of DETEX stems from the ability for software engineers to specify smells at a high level of abstraction using a consistent vocabulary and domain-specific language for automatically generating detection algorithms. Using DETEX, we specify four well-known design smells: the antipatterns Blob, Functional Decomposition, Spaghetti Code, and Swiss Army Knife, and their 15 underlying code smells, and we automatically generate their detection algorithms. We apply and validate the detection algorithms in terms of precision and recall on XERCES v2.7.0, and discuss the precision of these algorithms on 11 open-source systems.

In the software engineering literature, many works claim that the use of design patterns improves the comprehensibility of programs and, more generally, their maintainability. Yet, little work attempted to study the impact of design patterns on the developers' tasks of program comprehension and modification. We design and perform an experiment to collect data on the impact of the visitor pattern on comprehension and modification tasks with class diagrams. We use an eye-tracker to register saccades and fixations, the latter representing the focus of the developers' attention. Collected data show that the visitor pattern plays a role in maintenance tasks: class diagrams with its canonical representation requires less efforts from developers.

This work presents a descriptive and analytic study of classes playing zero, one, or two roles in six different design patterns (and combinations thereof). First, we answer three research questions showing that (1) classes playing one or two roles do exist in programs and are not negligible and that there are significant differences among the (2) internal (class metrics) and (3) external (change-proneness) characteristics of classes playing zero, one, or two roles. Second, we revisit a previous work on design patterns and changeability and show that its results were, in a great part, due to classes playing two roles. Third, we exemplify the use of the study results to provide a ranking of the occurrences of the design patterns identified in a program. The ranking allows developers to balance precision and recall.

The working session focuses on the use of eye-tracking technology to assess, understand, and evaluate tools and techniques for program comprehension. An introduction to the technology and tools of eye-tracking will be presented. A discussion of how these tools augment existing evaluation mechanism in the context of program comprehension will follow. Research directions and open problems will be a main topic.

Source code cloning does not happen within a single system only. It can also occur between one system and another. We use the term code sibling to refer to a code clone that evolves in a different system than the code from which it originates. Code siblings can only occur when the source code copyright owner allows it and when the conditions imposed by such license are not incompatible with the license of the destination system. In some situations copying of source code fragments are allowed—legally—in one direction, but not in the other. In this paper, we use clone detection, license mining and classification, and change history techniques to understand how code siblings—under different licenses—flow in one direction or the other between Linux and two BSD Unixes, FreeBSD and OpenBSD. Our results show that, in most cases, this migration appears to happen according to the terms of the license of the original code being copied, favoring always copying from less restrictive licenses towards more restrictive ones. We also discovered that sometimes code is inserted to the kernels from an outside source.

Undocumented software systems are a common challenge for developers performing maintenance and/or reuse. The challenge is two-fold: (1) when no comments or documentation exist, it is difficult for developers to understand how a system works; (2) when no requirements exist, it is difficult to know what the system actually does. We present a method, named ReORe (Reuse or Rewrite) that assists developers in recovering requirements for a competitor system and in deciding if they should reuse parts of their existing system or rewrite it from scratch. Our method requires source code and executable for the system and assumes that requirements are preliminarily recovered. We apply ReORe to Lynx, a Web browser written in C. We provide evidence of ReORe accuracy: 56% for validation based on textual and static analysis and 94% for the final validation using dynamic analysis.

Analyzing the change-proneness of design patterns and the kinds of changes occurring to classes playing role(s) in some design pattern(s) during software evolution poses the basis for guidelines to help developers who have to choose, apply or maintain design patterns. Building on previous work, this paper shifts the focus from design patterns as wholes to the finer-grain level of design pattern roles. The paper presents an empirical study to understand whether there are roles that are more change-prone than others and whether there are changes that are more likely to occur to certain roles. The study relies on data extracted from the source code repositories of three different systems (JHotDraw, Xerces, and Eclipse-JDT) and from 12 design patterns. Results obtained confirm the intuitive behavior about changeability of many roles in design motifs, but also warns about properly designing parts of the motif subject to frequent changes.

Inheritance is an important mechanism when developing object-oriented programs with class-based programming languages: it enables subtyping, polymorphism, and code reuse. Inheritance is also known as a difficult feature to grasp and to use correctly because of its many purposes. We propose a model of inheritance to help understand class hierarchies of class-based object-oriented programs. We define metrics and rules to highlight interesting classes and behaviours with respect to inheritance. Thus, we provide the programmer with insight on how inheritance is used in a program. We illustrate our approach on JHotDraw and validate it further on three other programs: ArgoUML, Azureus, and Log4J. We also show thatour model can describe existing rules, such as micro patterns.

The concern location problem is to identify the source code within a program related to the features, requirements, or other concerns of the program. This problem is central to program development and maintenance. We present a new technique called prune dependency analysis that can be combined with existing techniques to dramatically improve the accuracy of concern location. We developed CERBERUS, a potent hybrid technique for concern location that combines information retrieval, execution tracing, and prune dependency analysis. We used CERBERUS to trace the 360 requirements of RHINO, a 32,134 line Java program that implements the ECMAScript international standard. In our experiment, prune dependency analysis boosted the recall of information retrieval by 155% and execution tracing by 104%. Moreover, we show that our combined technique outperformed the other techniques when run individually or in pairs.

Design patterns are important in object-oriented programming because they offer design motifs, elegant solutions to recurrent design problems, which improve the quality of software systems. Design motifs facilitate system maintenance by helping to understand design and implementation. However, after implementation, design motifs are spread throughout the source code and are thus not directly available to maintainers. We present DeMIMA, an approach to identify semi-automatically micro-architectures that are similar to design motifs in source code and to ensure the traceability of these micro-architectures between implementation and design. DeMIMA consists of three layers: two layers to recover an abstract model of the source code, including binary class relationships, and a third layer to identify design patterns in the abstract model. We apply DeMIMA to five open-source systems and, on average, we observe 34% precision for the considered 12 design motifs. Through the use of explanation-based constraint programming, DeMIMA ensures 100% recall on the five systems. We also apply DeMIMA on 33 industrial components.

Identifiers represent an important source of information for programmers understanding and maintaining a system. Self-documenting identifiers reduce the time and effort necessary to obtain the level of understanding appropriate for the task at hand. While the role of the lexicon in program comprehension has long been recognized, only a few works have studied the quality and enhancement of the identifiers and no works have studied the evolution of the lexicon. In this paper, we characterize the evolution of program identifiers in terms of stability metrics and occurrences of renaming. We assess whether an evolution process similar to the one occurring for the program structure exists for identifiers. We report data and results about the evolution of three large systems, for which several releases are available. We have found evidence that the evolution of the lexicon is more limited and constrained than the evolution of the structure. We argue that the different evolution results from several factors including the lack of advanced tool support for lexicon construction, documentation, and evolution.

The Ptidej project started in 2001 to study code generation from and identification of design patterns. Since then, it has evolved into a complete reverse-engineering tool suite that includes several identification algorithms for idioms, micro-patterns, design patterns, and design defects. It is a flexible tool suite that attempts to ease as much as possible the development of new identification and analysis algorithms. In this demonstration, we first present the key features of the tool suite and several identification algorithms. We then discuss the architecture and design choices of the tool suite and lessons learned in developing the suite.

Software engineers often need to identify design defects, recurring design problems that hinder the development process, to improve and assess the quality of their systems. However, this is di±cult because of the lack of specifications and tools. We propose Decor, a method to specify design defects systematically and to generate automatically detection algorithms. With this method, software engineers analyse and specify design defects at a high-level of abstraction using a unified vocabulary and dedicated language for generating detection algorithms

This paper recasts the problem of feature location in source code as a decision-making problem in the presence of uncertainty. The solution to the problem is formulated as a combination of the opinions of different experts. The experts in this work are two existing techniques for feature location: a scenario-based probabilistic ranking of events and an information-retrieval-based technique that uses latent semantic indexing. The combination of these two experts is empirically evaluated through several case studies, which use the source code of the Mozilla Web browser and the Eclipse integrated development environment. The results show that the combination of experts significantly improves the effectiveness of feature location as compared to each of the experts used independently

The paper recasts the problem of feature location in source code as a decision-making problem in the presence of uncertainty. The main contribution consists in the combination of two existing techniques for feature location in source code. Both techniques provide a set of ranked facts from the software, as result to the feature identification problem. One of the techniques is based on a scenario based probabilistic ranking of events observed while executing a program under given scenarios. The other technique is defined as an information retrieval task, based on the latent semantic indexing of the source code. We show the viability and effectiveness of the combined technique with two case studies. A first case study is a replication of feature identification in Mozilla, which allows us to directly compare the results with previously published data. The other case study is a bug location problem in Mozilla. The results show that the combined technique improves feature identification significantly with respect to each technique used independently

Maintenance is recognised as the most difficult and expansive activity of the software development process. Numerous techniques and processes have been proposed to ease the maintenance of software. In particular, several authors published design defects formalising "bad" solutions to recurring design problems (e.g., anti-patterns, code smells). We propose a language and a framework to express design defects synthetically and to generate detection algorithms automatically. We show that this language is sufficient to describe some design defects and to generate detection algorithms, which have a good precision. We validate the generated algorithms on several programs

Feature identification is a technique to identify the source code constructs activated when exercising one of the features of a program. We propose new statistical analyses of static and dynamic data to accurately identify features in large multithreaded object-oriented programs. We draw inspiration from epidemiology to improve previous approaches to feature identification and develop an epidemiological metaphor. We build our metaphor on our previous approach to feature identification, in which we use processor emulation, knowledge-based filtering, probabilistic ranking, and metamodeling. We carry out three case studies to assess the usefulness of our metaphor, using the "save a bookmark" feature of Web browsers as an illustration. In the first case study, we compare our approach with three previous approaches (a naive approach, a concept analysis-based approach, and our previous probabilistic approach) in identifying the feature in MOZILLA, a large, real-life, multithreaded object-oriented program. In the second case study, we compare the implementation of the feature in the FIREFOX and MOZILLA Web browsers. In the third case study, we identify the same feature in two more Web browsers, Chimera (in C) and ICEBrowser (in Java), and another feature in JHOTDRAW and XFIG, to highlight the generalizability of our metaphor

Feature identification is a well-known technique to identify subsets of a program source code activated when exercising a functionality. Several approaches have been proposed to identify features. We present an approach to feature identification and comparison for large object-oriented multi-threaded programs using both static and dynamic data. We use processor emulation, knowledge filtering, and probabilistic ranking to overcome the difficulties of collecting dynamic data, i.e., imprecision and noise. We use model transformations to compare and to visualise identified features. We compare our approach with a naive approach and a concept analysis-based approach using a case study on a real-life large object-oriented multi-threaded program, Mozilla, to show the advantages of our approach. We also use the case study to compare processor emulation with statistical profiling.

Existing reverse-engineering tools use algorithms based on vague and verbose definitions of UML constituents to recover class diagrams from source code. Thus, reverse-engineered class diagrams are neither abstract nor precise representations of source code and are of little interest for software engineers. We propose an exhaustive study of class diagram constituents with respect to their recovery from C++, Java, and Smalltalk source code. We exemplify our study with a tool suite, PTIDEJ, to reverse-engineer Java programs as UML class diagrams abstractly and precisely. The tool suite produces class diagrams that help software engineers in better understanding programs.

Reverse-engineered UML class diagrams are neither abstract nor precise representations of source code because of the loose definitions of UML constituents. Thus, they are of little interest for software maintainers. We perform an exhaustive study of UML class diagrams constituents with respect to their recovery from C++, Java, and Smalltalk source code. We implement a tool suite, Ptidej, to reverse engineer Java source code abstractly and precisely.

A discontinuity exists between object-oriented modeling and programming languages. This discontinuity arises from ambiguous concepts in modeling languages and a lack of corresponding concepts in programming languages. It is particularly acute for binary class relationships---association, aggregation, and composition. It hinders the traceability between software implementation and design, thus hampering software analysis. We propose consensual definitions of the binary class relationships with four minimal properties---exclusivity, invocation site, lifetime, and multiplicity. We describe algorithms to detect automatically these properties in source code and apply these on several frameworks. Thus, we bridge the gap between implementation and design for the binary class relationships, easing software analysis.

A discontinuity exists between modeling and object-oriented programming languages. This discontinuity is a consequence of ambiguous notions in modeling languages and lack of corresponding notions in object-oriented programming languages. It hinders the transition between software implementation and design and hampers software maintenance. This discontinuity is particularly acute for binary class relationships, such as the association, aggregation, and composition relationships. We present a solution to bridge the discontinuity between implementation and design for the binary class relationships: we propose consensual definitions of the binary class relationships in terms of four properties (exclusivity, invocation site, lifetime, multiplicity). We describe algorithms to detect these properties in Java source code.

To understand the behavior of a program, a maintainer reads some code, asks a question about this code, conjectures an answer, and searches the code and the documentation for confirmation of her conjecture. However, the confirmation of the conjecture can be error-prone and time-consuming because the maintainer has only static information at her disposal. She would benefit from dynamic information. In this paper, we present Caffeine, an assistant that helps the maintainer in checking her conjecture about the behavior of a Java program. Our assistant is a dynamic analysis tool that uses the Java platform debug architecture to generate a trace, i.e., an execution history, and a Prolog engine to perform queries over the trace. We present a usage scenario based on the n-queens problem, and two real-life examples based on the Singleton design pattern and on the composition relationship.

Design patterns ease the designing, understanding, and re-engineering of software. Achieving a well-designed piece of software requires a deep understanding and a good practice of design patterns. Understanding existing software relies on the ability to identify architectural forms resulting from the implementation of design patterns. Maintaining software involves spotting places that can be improved by using better design decisions, like those advocated by design patterns. Nevertheless, there is a lack of tools automatizing the use of design patterns to achieve well-designed pieces of software, to identify recurrent architectural forms, and to maintain software. We present a set of tools and techniques to help OO software practitioners design, understand, and re-engineer a piece of software using design-patterns. A first prototype tool, PATTERNS-BOX, provides assistance in designing the architecture of a new piece of software, while a second prototype tool, PTIDEJ, identifies design patterns used in an existing one. These tools, in combination, support maintenance by highlighting defects in an existing design, and by suggesting and applying corrections based on widely-accepted design pattern solutions.