Grey literature is essential to software engineering research as it captures practices and decisions that rarely appear in academic venues. However, collecting and assessing it at scale remains difficult because of their heterogeneous sources, formats, and APIs that impede reproducible, large-scale synthesis. To address this issue, we present GLiSE, a prompt-driven tool that turns a research topic prompt into platform-specific queries, gathers results from common software-engineering web sources (GitHub, Stack Overflow) and Google Search, and uses embedding-based semantic classifiers to filter and rank results according to their relevance. GLiSE is designed for reproducibility with all settings being configuration-based, and every generated query being accessible. In this paper, (i) we present the GLiSE tool, (ii) provide a curated dataset of software engineering grey-literature search results classified by semantic relevance to their originating search intent, and (iii) conduct an empirical study on the usability of our tool.

IoT systems are increasingly developed and deployed across various domains, where End-to-End (E2E) testing is critical to ensure reliability and expected behavior. However, generating comprehensive tests remains challenging due to the heterogeneity, distributed nature, and unique characteristics of IoT systems, which limit the effectiveness of generic test generation approaches. Recent studies demonstrated the effectiveness of Large Language Models (LLM) for test generation in traditional software systems. Building on this foundation, this study explores and evaluates four distinct approaches for generating E2E tests from use case specifications (UCSs) tailored to IoT systems. These include (1) a custom, (2) a single-stage LLM, (3) a multi-stage LLM, and (4) a hybrid approach combining custom and LLM capabilities. We evaluated these approaches on an IoT system, focusing on correctness and scenario coverage criteria. Experimental results indicate that all approaches perform well, with notable variations in specific aspects of test generation. The custom and hybrid approaches are more reliable in producing correctly structured and complete tests, with the hybrid approach slightly outperforming others. This study is a work in progress, requiring further investigation to fully realize its potential.

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.

Modern software development is a complex engineering process where developer code cohabits with an increasingly larger number of external open-source components. Even though these components facilitate sharing and reusing code along with other benefits related to maintenance and code quality, they are often the seeds of vulnerabilities in the software supply chain leading to attacks with severe consequences. Indeed, one common strategy used to conduct attacks is to exploit or inject other security flaws in new versions of dependency packages. It is thus important to keep dependencies updated in a software development project. Unfortunately, several prior studies have highlighted that, to a large extent, developers struggle to keep track of the dependency package updates, and do not quickly incorporate security patches. Therefore, automated dependency-update bots have been proposed to mitigate the impact and the emergence of vulnerabilities in open-source projects. In our study, we focus on Dependabot, a dependency management bot that has gained popularity on GitHub recently. It allows developers to keep a lookout on project dependencies and reduce the effort of monitoring the safety of the software supply chain. We performed a large empirical study on dependency updates and security pull requests to understand: (1) the degree and reasons of Dependabot’s popularity; (2) the patterns of developers’ practices and techniques to deal with vulnerabilities in dependencies; (3) the management of security pull requests (PRs), the threat lifetime, and the fix delay; and (4) the factors that significantly correlate with the acceptance of security PRs and fast merges. To that end, we collected a dataset of 9,916,318 pull request-related issues made in 1,743,035 projects on GitHub for more than 10 different programming languages. In addition to the comprehensive quantitative analysis, we performed a manual qualitative analysis on a representative sample of the dataset, and we substantiated our findings by sending a survey to developers that use dependency management tools. Our study shows that Dependabot dominates more than 65% of dependency management activity, mainly due to its efficiency, accessibility, adaptivity, and availability of support. We also found that developers handle dependency vulnerabilities differently, but mainly rely on the automation of PRs generation to upgrade vulnerable dependencies. Interestingly, Dependabot’s and developers’ security PRs are highly accepted, and the automation allows to accelerate their management, so that fixes are applied in less than one day. However, the threat of dependency vulnerabilities remains hidden for 512 days on average, and patches are disclosed after 362 days due to the reliance on the manual effort of security experts. Also, project characteristics, the amount of PR changes, as well as developer and dependency features seem to be highly correlated with the acceptance and fast merges of security PRs.

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.

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.

Code smells are the result of poor design choices within software systems that complexify source code and impede evolution and performance. Therefore, detecting code smells within software systems is an important priority to decrease technical debt. Furthermore, the emergence of mobile applications (apps) has brought new types of Android-specific code smells, which relate to limitations and constraints on resources like memory, performance and energy consumption. Among these Android-specific smells are those that describe inappropriate behaviour during the execution that may negatively impact software quality. Static analysis tools, however, show limitations for detecting these behavioural code smells and properly detecting behavioural code smells requires considering the dynamic behaviour of the apps. To dynamically detect behavioural code smells, we hence propose three contributions : (1) A method, the Dynamicsmethod, a step-by-step method for the specification and dynamic detection of Android behavioural code smells; (2) A tool, the Dynamicstool, implementing this method on seven code smells; and (3) A validation of our approach on 538 apps from F-Droidwith a comparison with the static analysis detection tools,aDoctorand Paprika, from the literature. Our method consists of four steps: (1) the specification of the code smells, (2) the instrumentation of the app, (3) the execution of the apps, and (4) the detection of the behavioural code smells. Our results show that many instances of code smells that cannot be detected with static detection tools are indeed detected with our dynamic approach with an average precision of 92.8% and an average recall of 53.4%.

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.

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.

Abstract Detecting vulnerabilities in software is a constant race between development teams and potential attackers. While many static and dynamic approaches have focused on regularly analyzing the software in its entirety, a recent research direction has focused on the analysis of changes that are applied to the code. VCCFinder is a seminal approach in the literature that builds on machine learning to automatically detect whether an incoming commit will introduce some vulnerabilities. Given the influence of VCCFinder in the literature, we undertake an investigation into its performance as a state-of-the-art system. To that end, we propose to attempt a replication study on the VCCFinder supervised learning approach. The insights of our failure to replicate the results reported in the original publication informed the design of a new approach to identify vulnerability-contributing commits based on a semi-supervised learning technique with an alternate feature set. We provide all artefacts and a clear description of this approach as a new reproducible baseline for advancing research on machine learning-based identification of vulnerability-introducing commits.

The rise of mobile apps as new software systems led to the emergence of new development requirements regarding performance. Development practices that do not respect these requirements can seriously hinder app performances and impair user experience, they qualify as code smells. Mobile code smells are generally associated with inexperienced developers who lack knowledge about the framework guidelines. However, this assumption remains unverified and there is no evidence about the role played by developers in the accrual of mobile code smells. In this paper, we therefore study the contributions of developers related to Android code smells. To support this study, we propose Sniffer, an open-source toolkit that mines Git repositories to extract developers' contributions as code smell histories. Using Sniffer, we analysed 255k commits from the change history of 324 Android apps. We found that the ownership of code smells is spread across developers regardless of their seniority. There are no distinct groups of code smell introducers and removers. Developers who introduce and remove code smells are mostly the same.

Abstract Large‐scale corrective and perfective maintenance is often automated thanks to rewriting rules using tools such as Python2to3, Spoon, or Coccinelle. Such tools consider these rules as black‐boxes and compose multiple rules by chaining them: giving the output of a given rewriting rule as input to the next one. It is up to the developer to identify the right order (if it exists) among all the different rules to yield the right program. In this paper, we define a formal model compatible with the black‐box assumption that reifies the modifications (Δs) made by each rule. Leveraging these Δs, we propose a way to safely compose multiple rules when applied to the same program by (a) ensuring the isolated application of the different rules and (b) identifying unexpected behaviors that were silently ignored before. We assess this approach on two large‐scale case studies: (a) identifying conflicts in the Linux source‐code automated maintenance and (b) fixing energy antipatterns existing in Android applications available on GitHub.

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.

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.

Android code smells are bad implementation practices within Android applications (or apps) that may lead to poor software quality. These code smells are known to degrade the performance of apps and to have an impact on energy consumption. However, few studies have assessed the positive impact on energy consumption when correcting code smells. In this paper, we therefore propose a tooled and reproducible approach, called HOT-PEPPER, to automatically correct code smells and evaluate their impact on energy consumption. Currently, HOT-PEPPER is able to automatically correct three types of Android-specific code smells: Internal Getter/Setter, Member Ignoring Method, and HashMap Usage. HOT-PEPPER derives four versions of the apps by correcting each detected smell independently, and all of them at once. HOT-PEPPER is able to report on the energy consumption of each app version with a single user scenario test. Our empirical study on five open-source Android apps shows that correcting the three aforementioned Android code smells effectively and significantly reduces the energy consumption of apps. In particular, we observed a global reduction in energy consumption by 4,83% in one app when the three code smells are corrected. We also take advantage of the flexibility of HOT-PEPPER to investigate the impact of three picture smells (bad picture format, compression, and bitmap format) in sample apps. We observed that the usage of optimised JPG pictures with the Android default bitmap format is the most energy efficient combination in Android apps. We believe that developers can benefit from our approach and results to guide their refactoring, and thus improve the energy consumption of their mobile apps.

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.

Mobile apps are becoming complex software systems that must be developed quickly and evolve continuously to fit new user requirements and execution contexts. However, addressing these requirements may result in poor design choices, also known as antipatterns, which may incidentally degrade software quality and performance. Thus, the automatic detection and tracking of antipatterns in this apps are important activities in order to ease both maintenance and evolution. Moreover, they guide developers to refactor their applications and thus, to improve their quality. While antipatterns are well-known in object-oriented applications, their study in mobile applications is still in its infancy. In this paper, we analyze the evolution of mobile apps quality on 3, 568 versions of 106 popular Android applications downloaded from the Google Play Store. For this purpose, we use a tooled approach, called PAPRIKA, to identify 3 object-oriented and 4 Android-specific antipatterns from binaries of mobile apps, and to analyze their quality along evolutions.

Cloud patterns are described as good solutions to recurring design problems in a cloud context. These patterns are often inherited from Service Oriented Architectures or Object Oriented Architectures where they are considered good practices. However, there is a lack of studies that assess the benefits of these patterns for cloud applications. In this paper, we conduct an empirical study on a Restful application deployed in the cloud, to investigate the individual and the combined impact of three cloud patterns (i.e., Local Database proxy, Local Sharding-Based Router and Priority Queue Patterns) on Quality of Service (QoS). We measure the QoS using the application's response time, average, and maximum number of requests processed per seconds. Results show that cloud patterns doesn't always improve the response time of an application. In the case of the Local Database proxy pattern, the choice of algorithm used to route requests has an impact on response time, as well as the average and maximum number of requests processed per second. Combinations of patterns can significantly affect the QoS of applications. Developers and software architects can make use of these results to guide their design decisions.

In model-driven engineering, a model describes an aspect of a system. A model conforms to a metamodel that defines the concepts and relationships of a given domain. Metamodels are thus corner-stones of various meta-modeling activities that require a good understanding of the metamodels or parts of them. Current metamodel editing tools are based on standard visualization and navigation features, such as physical zooms. However, as soon as metamodels become larger, navigating through large metamodels becomes a tedious task that hinders their understanding. In this work, we promote the use of model slicing techniques to build visualization techniques dedicated to metamodels. We propose an approach based on model slicing, inspired from program slicing, to build interactive visualization techniques dedicated to metamodels. These techniques permit users to focus on metamodel elements of interest, which aims at improving the understand ability. This approach is implemented in a metamodel visualizer, called Explen.

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%.

The real value of Web services under the SOA paradigm lies in their ability to be assembled to obtain a new functionality. Assembling Web services can be achieved through a standard called BPEL, which creates executable processes by orchestrating Web service invocations. The problem with BPEL is the inability to separate the process description from its realization. In other words, it requires a prior retrieval of concrete Web services, which can be very challenging regarding the issues surrounding service discovery and selection. In this paper, we propose to separate a BPEL process description from its realization. We extend the notion of abstract BPEL processes, in order to enable developers to describe their desired orchestrations abstractly without identifying concrete services, according to three levels: the needed functionality, the expected QoS levels, and the composition flow. Then, the abstract BPEL process is realized by a selection framework that automatically discovers, classifies, and selects suitable services to render the process executable. Backup services are also discovered to assure the continuity of the realized process.

Building a composite application based on Web services has become a real challenge regarding the large and diverse service space nowadays. Especially when considering the various functional and non-functional capabilities that Web services may afford and users may require. In this paper, we propose an approach for facilitating Web service selection according to user requirements. These requirements specify the needed functionality and expected QoS, as well as the composability between each pair of services. The originality of our approach is embodied in the use of Relational Concept Analysis (RCA), an extension of Formal Concept Analysis (FCA). Using RCA, we classify services by their calculated QoS levels and composability modes. We use a real case study of 901 services to show how to accomplish an efficient selection of services satisfying a specified set of functional and non-functional requirements.

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 .

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.

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

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