Benoit Combemale’s research while affiliated with University of Rennes and other places

Software modeling and digital twins are transforming the way software engineers design, operate, and maintain complex systems. In this column, we highlight cutting-edge research presented at the ACM/IEEE 27th International Conference on Model-Driven Engineering Languages and Systems (MODELS 2024) and the 1st International Conference on Engineering Digital Twins (EDTconf 2024). The selected papers tackle critical challenges in improving system understanding, enhancing stakeholder communication, streamlining design and development processes, optimizing lifecycles, and enabling seamless integration of complex systems.

As software grows increasingly complex, the quantity and diversity of concerns to be addressed also rises. To answer this diversity of concerns, developers may end up using multiple programming languages in a single software project, a practice known as polyglot programming. This practice has gained momentum with the rise of execution platforms capable of supporting polyglot systems. However, despite this momentum, there is a notable lack of development tooling support for developers working on polyglot programs, such as in debugging facilities. Not all polyglot execution platforms provide debugging capabilities, and for those that do, implementing support for new languages can be costly. This paper addresses this gap by introducing a novel debugger framework that is language-agnostic yet leverages existing language-specific debuggers. The proposed framework is dynamically extensible to accommodate the evolving combination of languages used in polyglot software development. It utilizes the Debug Adapter Protocol (DAP) to integrate and coordinate existing debuggers within a debugging session. We found that using our approach, we were able to implement polyglot debugging support for three different languages with little development effort. We also found that our debugger did not introduce an overhead significant enough to hinder debugging tasks in many scenarios; however performance did deteriorate with the amount of polyglot calls, making the approach not suitable for every polyglot program structure. The effectiveness of this approach is demonstrated through the development of a prototype, PolyDebug, and its application to use cases involving C, JavaScript, and Python. We evaluated PolyDebug on a dataset of traditional benchmark programs, modified to fit our criteria of polyglot programs. We also assessed the development effort by measuring the source lines of code (SLOC) for the prototype as a whole as well as its components. Debugging is a fundamental part of developing and maintaining software. Lack of debug tools can lead to difficulty in locating software bugs and slow down the development process. We believe this work is relevant to help provide developers proper debugging support regardless of the runtime environment.

In response to the growing demand for groundwater flow models, we present HydroModPy, an open-source toolbox designed to automate their deployment at the catchment scale. Built on top of the MODFLOW-enabling FloPy library, HydroModPy combines the robust WhiteboxTools toolbox for geospatial analysis and the well-validated MODFLOW code for groundwater modeling. This Python-based toolbox streamlines the construction, calibration, and analysis of unconfined aquifer models while adhering to FAIR (Findable, Accessible, Interoperable, and Reusable) principles. It enhances model reproducibility through editable Python code, supports multi-site deployment, and provides compatibility with alternative groundwater flow solvers. Furthermore, it integrates pre- and post-processing functionalities to simplify workflows. The toolbox enables catchment delineation and hydrological feature extraction from DEMs, followed by semi-automatic model construction and advanced visualization of hydraulic head and flow results. Users can choose from predefined aquifer structures and hydraulic properties such as exponential decay of hydraulic conductivity and porosity with depth or import complex 3D geological models. HydroModPy outputs can be exported in standard formats (e.g., raster, shapefile, netCDF), including water table elevation, water table depth, groundwater storage, groundwater-dependent hydrographic network and streamflow rates, and subsurface residence times. HydroModPy is tailored for the deployment in diverse geomorphological and hydrological settings, enabling the testing and exploration of aquifer models under varying recharge conditions. Its deployment capabilities are demonstrated in complex shallow basement and crystalline aquifers, where topography and geology primarily govern groundwater flow dynamics from hillslope to catchment scales. As an open-source toolbox, HydroModPy is designed for the community and actively encourages contributions from its users. It supports research in hydro(geo)logy and land and water management, while also providing valuable opportunities for teaching and education.

The acceleration of software development and delivery requires rigorous continuous testing and deployment of software systems, which are being deployed in increasingly diverse, complex, and dynamic environments. In recent years, the popularization of DevOps and integrated software forges like GitLab and GitHub has largely democratized Continuous Integration (CI) practices for a growing number of software. However, this trend intersects significantly with global energy consumption concerns and the growing demand for frugality in the Information and Communication Technology (ICT) sector. CI pipelines typically run in data centers which contribute significantly to the environmental footprint of ICT, yet there is little information available regarding their environmental impact. This article aims to bridge this gap by conducting the first large-scale analysis of the energy footprint of CI pipelines implemented with GitHub Actions and to provide a first overview of the energy impact of CI. We collect, instrument, and reproduce 838 workflows from 396 Java repositories hosted on GitHub to measure their energy consumption. We observe that the average unitary energy cost of a pipeline is relatively low, at 10 Wh. However, due to repeated invocations of these pipelines in real settings, the aggregated energy consumption cost per project is high, averaging 22 kWh. When evaluating CO2 emissions based on regional Wh-to-CO2 estimates, we observe that the average aggregated CO2 emissions are significant, averaging 10.5 kg. To put this into perspective, this is akin to the emissions produced by driving approximately 100 kilometers in a typical European car (110 gCO2/km). In light of our results, we advocate that developers should have the means to better anticipate and reflect on the environmental consequences of their CI choices when implementing DevOps practices.