International audience

Producing energy-efficient software is gaining increasing attention in both industry and research communities. In this context, the company Berger-Levrault, an international software publisher, aims to better understand and monitor the energy behaviour of its software systems to support the development of more energy-efficient products. However, achieving this objective remains challenging because developers lack feedback mechanisms that show how their implementation and testing choices affect the software system’s energy consumption.

International audience

International audience

Abstract Recommender systems for requirements are typically built on the assumption that similar requirements can be used as proxies to retrieve similar software. When a stakeholder proposes a new requirement, natural language processing (NLP)-based similarity metrics can be exploited to retrieve existing requirements, and in turn, identify previously developed code. Several NLP approaches for similarity computation between requirements are available. However, there is little empirical evidence on their effectiveness for code retrieval. This study compares different NLP approaches, from lexical ones to semantic, deep-learning techniques, and correlates the similarity among requirements with the similarity of their associated software. The evaluation is conducted on real-world requirements from two industrial projects from a railway company. Specifically, the most similar pairs of requirements across two industrial projects are automatically identified using six language models. Then, the trace links between requirements and software are used to identify the software pairs associated with each requirements pair. The software similarity between pairs is then automatically computed with JPLag. Finally, the correlation between requirements similarity and software similarity is evaluated to see which language model shows the highest correlation and is thus more appropriate for code retrieval. In addition, we perform a focus group with members of the company to collect qualitative data. Results show a moderately positive correlation between requirements similarity and software similarity, with the pre-trained deep learning-based BERT language model with preprocessing outperforming the other models. Practitioners confirm that requirements similarity is generally regarded as a proxy for software similarity. However, they also highlight that additional aspect comes into play when deciding software reuse, e.g., domain/project knowledge, information coming from test cases, and trace links. Our work is among the first ones to explore the relationship between requirements and software similarity from a quantitative and qualitative standpoint. This can be useful not only in recommender systems but also in other requirements engineering tasks in which similarity computation is relevant, such as tracing and change impact analysis.

The microservice-oriented architecture (MSA) is an architectural style which involves organizing an application as of small independent services, each oriented towards one business functionality while being data autonomous. In pursuit of modernizing their software to take advantage of the Cloud, companies have been eager to migrate their monolithic legacy software towards an MSA. This migration necessitates an identification phase to reorganize classes around the monolith’s functionalities as a set of microservice candidates. However, most identification approaches fail to utilize the monolith’s internal multilayered architecture to identify those functionalities, and thus the microservices. As a consequence, ignoring the internal multilayered architecture increases the risk of identifying microservice by their technical layer which is recognized as a conceptual anti-pattern. In this paper, we explore the impact of the multi-layer architecture in monolithic applications during the identification to develop a semi-automatic approach that relies on it to identify an MSA. Particularly, we analyze the presentation layer to determine the endpoints of each business functionality of the monolith. From these endpoints, we apply a vertical decomposition to identify the necessary classes to implement each feature as a microservice. In the process, we also define the bounded context of each microservice during the vertical decomposition of the data-access layer. For the evaluation, we implemented a model-driven process and applied it on a set of varying open-source applications commonly used in the literature. We compared the results of approach with and without the reverse-engineering of the internal architecture to measure the impact of our approach on the identification of quality microservices. Using decomposition metrics (e.g., MoJoFM, c2ccvg), we were able to measure a significant positive impact.

International audience

In a collaboration with Berger-Levrault, a major IT company, we are working on the migration of GWT applications to Angular. We focus on the GUI aspect of this migration which requires a framework switch (GWT to Angular) and a programming language switch (Java to TypeScript). Previous work identified that the GUI can be split into the UI structure and the GUI behavioral code. GUI behavioral code is the code executed when the user interacts with the UI. Although the migration of UI structure has already been studied, the migration of the GUI behavioral code has not. To help developers during the migration of their applications, we propose a generic approach in four steps that uses a meta-model to represent the GUI behavioral code. This approach includes a separation of the GUI behavioral code into events (caller code) and the code executed when an event is fired (called code). We present the approach and its implementation for a real industrial case study. The application comprises 470 Java (GWT) classes representing 56 web pages. We give examples of the migrated code. We evaluate the quality of the generated code with standard tools (SonarQube, codelizer) and compare it to another Java to TypeScript converter. The results show that our code has 53% fewer warnings and rule violations for SonarQube, and 99% fewer for codelizer.

International audience

Software developers rely on the clone-and-own approach to rapidly develop software product variants (PVs) that meet variability in market needs. To improve the comprehension of how PVs are evolved and varied, we analyze the clone-and-own practices applied by developers of these PVs. We perform an empirical study on 75 android families to gain insights about observable phenomena related to the commonality and variability between the source code of PVs of these families. In particular, we study three research questions to identify the commonality and variability related to the organization of source code files, cloning Java methods, and configuration parameters of AndroidManifest.xml files. The results show that cloning packages, Java files and Java methods is a common practice used by developers of all android families. Maintainers should put efforts for managing the diverse implementations (bodies) of the modified cloned methods and it is essential to consider the commonality and variability of configuration parameters.

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.

The reuse at the component level is generally more effective than the one at the object-oriented class level. This is due to the granularity level where components expose their functionalities at an abstract level compared to the fine-grained object-oriented classes. Moreover, components clearly define their dependencies through their provided and required interfaces in an explicit way that facilitates the understanding of how to reuse these components. Therefore, several component identification approaches have been proposed to identify components based on the analysis object-oriented software applications. Nevertheless, most of the existing component identification approaches did not consider co-usage dependencies between API classes to identify classes/methods that can be reused to implement a specific scenario. In this paper, we propose an approach to identify reusable software components in object-oriented APIs, based on the interactions between client applications and the targeted API. As we are dealing with actual clients using the API, dynamic analysis allows to better capture the instances of API usage. Approaches using static analysis are usually limited by the difficulty of handling dynamic features such as polymorphism and class loading. We evaluate our approach by applying it to three Java APIs with eight client applications from the DaCapo benchmark. DaCapo provides a set of pre-defined usage scenarios. The results show that our component identification approach has a very high precision.

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.

Large object-oriented applications have complex and numerous dependencies, and usually do not have explicit software architectures. Therefore they are hard to maintain, and parts of them are difficult to reuse. Component-based development paradigm emerged for improving these aspects and for supporting effective maintainability and reuse. It provides better understandability through a high-level architecture view of the application. Thereby migrating object-oriented applications to component-based ones will contribute to improve these characteristics (maintainability and reuse). In this paper, we propose an approach to automatically transform object-oriented applications to component-based ones. More particularly, the input of the approach is the result provided by software architecture recovery: a component-based architecture description. Then, our approach transforms the object-oriented source code in order to produce deployable components. We focus in this paper on the transformation of source code related to instantiation and inheritance dependencies between classes that are in different components. We experimented the proposed solution in the transformation of a collection of Java applications into the OSGi framework. The experimental results are discussed in this paper.