Informal diagrams created in general-purpose diagramming tools are widely used in software architecture because they are quick to produce and easy to share. However, the lack of constraints in such tools often yields inconsistent notations and ad-hoc conventions, which in turn invite misinterpretation when diagrams are read outside their original context. Dedicated modeling languages and environments can mitigate these issues but are frequently resisted due to steep learning curves and disruptive adoption costs. Building on the flexible modeling paradigm, this paper proposes an approach to the lightweight formalization of informal diagrams. Grounded in observed industrial challenges and prior work on flexible modeling, we derive a set of design principles and instantiate them in an approach realized as a Draw.io plugin. We propose an approach that addresses challenges from industrial settings by enabling practitioners to introduce structure incrementally into the informal diagrams they already create, thereby helping resolve notational inconsistency and clarify meaning. Moreover, we show how our approach satisfies the guiding flexible modeling principles by introducing these model-like benefits without compromising the accessibility and speed of informal diagramming as valued in practice. The contribution enhances clarity and consistency within familiar workflows and lays the groundwork for subsequent capabilities such as rapid dissemination of conventions, enterprise-level aggregation, and additional quality checks should organizations choose to adopt them. © 2026, Science and Technology Publications, Lda. All rights reserved.

Software-intensive systems are characterized by intricate interactions, distributed structures, and ongoing evolution posing notable challenges for traceability, change analysis, and decision support. Modeling and versioning practices are widely used to manage this complexity; however, in practice, they are often fragmented, limiting the value that organizations can derive from them. To address this challenge, we map modeling and versioning practices to the benefits they enable, providing a structured framework for practitioners to assess their current practices and identify opportunities for incremental improvement. Building on findings from our previous interview study with multiple companies, together with insights from the literature, we identify four levels of modeling formality, five levels of versioning sophistication, and four categories of benefits, summarized in two mapping tables. Our contributions include a practitioner-oriented roadmap that helps teams reflect on current modeling and versioning practices, anticipate achievable benefits, and identify incremental adjustments that can add value with minimal overhead. An initial validation with industry representatives confirms the practical relevance of the roadmap and highlights its potential to guide structured reflection and improvement of modeling and versioning practices.

Abstract In software engineering practice, models created for communication and documentation are often informal. This limits the applicability of powerful model-driven engineering mechanisms. Understanding the motivations and use of informal diagrams can improve modelling techniques and tools, by bringing together the benefits of both informal diagramming and modelling using modelling languages and modelling tools. In this paper, we report on an initial exploration effort to investigate the use of informal diagramming in both open-source software repositories and industrial software engineering practices. We carried out a repository mining study on open-source software repositories seeking informal diagrams and classified them according to what they represent and how they are used. Additionally, we describe industrial practices that rely to some extent on informal diagramming, as gathered through unstructured interviews with practitioners. We compare the findings from these data sources and discuss how informal diagrams are used in practice.

In this article, we discuss how we can facilitate the growing need for early validation and verification (V&V) of system behaviour in Model-Based Systems Engineering (MBSyE). Several aspects, such as reducing cost and time to market, push companies towards integration of V&V methods earlier in development to support effective decision-making. One foundational methodology seeing increased attention in industry is the use of MBSyE, which brings benefits of models with well-defined syntax and semantics to support V&V activities, rather than relying on natural language text documentation. Despite their promise, industrial adoption of these practices is still challenging. This article presents a vision for readily available early V&V . We present a summary of the literature on early V&V in MBSyE and position existing challenges regarding potential solutions and future investigations towards this vision. We elaborate our vision by means of challenges with a specific emphasis on early V&V of system behaviour . We identify three specific challenge areas: Creating and managing Models , Organisational systems engineering aspects, and early V&V Methods . Finally, we outline a road-map to address these categories of challenges, in which we propose the transfer of established best practices from the software engineering domain to support emerging technologies in the systems engineering domain.

In the development of modern software-intensive systems, security aspects are increasingly emphasized, with new laws and regulations putting more demands on manufacturers. Requirements elicitation must therefore carefully consider security aspects. The literature contains various frameworks that have been proposed to aid in the elicitation of these types of requirements. We are interested to understand how, in industrial practice, persons responsible for cybersecurity reason about so-called “security requirements”. To find out, we perform eight semi-structured interviews with experts having leading roles in cybersecurity in large companies. We identify the concepts that they leverage when reasoning about security requirements, what other aspects they look at when identifying security requirements, how they differ between security requirements and other requirements, and what their definition of a security requirement is. In this paper, we report on this interview study and our analysis of it. We highlight the commonalities and crucial differences between experts' reasoning, and a surprising spread of conclusions regarding the identification of example requirements as being security requirements or not. Our analysis opens a new perspective on how to deal with security requirements, we hypothesize the benefits of using multiple approaches for elicitation and a single approach for requirements specification.

Abstract Understanding the behaviour of a system’s API can be hard. Giving users access to relevant examples of how an API behaves has been shown to make this easier for them. In addition, such examples can be used to verify expected behaviour or identify unwanted behaviours. Methods for automatically generating examples have existed for a long time. However, state-of-the-art methods rely on either white-box information, such as source code, or on formal specifications of the system behaviour. But what if you do not have access to either? This may be the case, for example, when interacting with a third-party API. In this paper, we present an approach to automatically generate relevant examples of behaviours of an API, without requiring either source code or a formal specification of behaviour. Evaluation on an industry-grade REST API shows that our method can produce small and relevant examples that can help engineers to understand the system under exploration.

Abstract A common way of exposing functionality in contemporary systems is by providing a Web-API based on the REST API architectural guidelines. To describe REST APIs, the industry standard is currently OpenAPI-specifications. Test generation and fuzzing methods targeting OpenAPI-described REST APIs have been a very active research area in recent years. An open research challenge is to aid users in better understanding their API, in addition to finding faults and to cover all the code. In this paper, we address this challenge by proposing a set of behavioural properties, common to REST APIs, which are used to generate examples of behaviours that these APIs exhibit. These examples can be used both (i) to further the understanding of the API and (ii) as a source of automatic test cases. Our evaluation shows that our approach can generate examples deemedrelevantfor understanding the system and for a source of test generation by practitioners. In addition, we show that basing test generation on behavioural properties provides tests that are less dependent on the state of the system, while at the same time yielding a similar code coverage as state-of-the-art methods in REST API fuzzing in a given time limit.

Today, a plethora of programming languages exists, each better suited for a particular concern. For example, Python is suited for data analysis but not web development, whereas JavaScript is the inverse. As software complexity grows and needs to address multiple concerns, different programming languages are often used in combination, despite the burden of bridging them (e.g., using Java Native Interface). Polyglot programming emerged as a solution allowing the seamless mixing of multiple programming languages. GraalVM and PolyNote are examples of runtimes allowing polyglot programming. However, there is a striking lack of support at design time for building and analyzing polyglot code. To the best of our knowledge, there is no uniform language-agnostic way of reasoning over multiple languages to provide seamless code analysis, since each language comes with its own form of Abstract Syntax Trees (AST). In this paper, we present an approach to build a uniform yet polyglot AST over polyglot code, so that it is easier to perform global analysis. We first motivate this challenge and identify the main requirements for building a polyglot AST. We then propose a proof of concept implementation of our solutions on GraalVM’s polyglot API. On top of the polyglot AST, we demonstrate the ability to implement several polyglot-specific analysis services, namely auto-completion, consistency checking, type inference, and rename refactoring. Our evaluation on three polyglot projects taken from GitHub, and involving JavaScript and Python code, shows that we can build a polyglot AST without significant overhead. We also demonstrate the usefulness of the polyglot analysis services through the provided automation, as well as their scalability.

Abstract This article presents the state of practice of consistency management in thirteen industrial model-based development settings. Our analysis shows a tight coupling between adopting shorter development cycles and increasingly pressing consistency management challenges. We find that practitioners desire to adopt shorter development cycles, but immature modeling practices slow them down. We describe the different patterns that emerge from the various industrial settings. There is an opportunity for researchers to provide practitioners with a migration path toward practices that enable more automated consistency management, and ultimately, continuous model-based development.

In this paper, we report on a case study in an industrial setting where code is generated from models, and, for various reasons, that generated code is then manually modified. To enhance the maintainability of both models and code, consistency between them is imperative. A first step towards establishing that consistency is to identify the manual changes that were made to the code after it was generated and deployed. Identifying the delta is not straightforward and requires pre-processing of the artifacts. The main mechanics driving our solution are higher-order transformations, which make the implementation scalable and robust to small changes in the modeling language. We describe the specific industrial setting of the problem, as well as the experiences and lessons learned from developing, implementing, and validating our solution together with our industrial partner.

Co-evolution of metamodels and conforming models is a known challenge in model-driven engineering. A variation of co-evolution occurs in model-based software product line engineering, where it is needed to efficiently co-evolve various products together with the single common platform from which they are derived. In this paper, we aim to alleviate manual efforts during this co-evolution process in an industrial setting where Simulink models are partially reused across various products. We propose and implement an approach providing support for the co-evolution of reusable model fragments. A demonstration on a realistic example model shows that our approach yields a correct co-evolution result and is feasible in practice, although practical application challenges remain. Furthermore, we discuss insights from applying the approach within the studied industrial setting.

Model-based development and continuous integration each separately are methods to improve the productivity of development of complex modern software systems. We investigate industrial adoption of these two phenomena in combination, i.e., applying continuous integration practices in model-based development projects. Through semi-structured interviews, eleven engineers at three companies with different modelling practices share their views on perceived and experienced impediments to this adoption. We find some cases in which this introduction is undesired and expected to not be beneficial. For other cases, we find and categorize several impediments and discuss how they are dealt with in industrial practice. Model synchronization and tool interoperability are found the most challenging to overcome and the ways in which they are circumvented in practice are detrimental for introducing continuous integration.

Recent years have seen an increasing attention to social aspects of software engineering, including studies of emotions and sentiments experienced and expressed by the software developers. Most of these studies reuse existing sentiment analysis tools such as SentiStrength and NLTK. However, these tools have been trained on product reviews and movie reviews and, therefore, their results might not be applicable in the software engineering domain. In this paper we study whether the sentiment analysis tools agree with the sentiment recognized by human evaluators (as reported in an earlier study) as well as with each other. Furthermore, we evaluate the impact of the choice of a sentiment analysis tool on software engineering studies by conducting a simple study of differences in issue resolution times for positive, negative and neutral texts. We repeat the study for seven datasets (issue trackers and Stack Overflow questions) and different sentiment analysis tools and observe that the disagreement between the tools can lead to diverging conclusions. Finally, we perform two replications of previously published studies and observe that the results of those studies cannot be confirmed when a different sentiment analysis tool is used.

Recent years have seen an increasing attention to social aspects of software engineering, including studies of emotions and sentiments experienced and expressed by the software developers. Most of these studies reuse existing sentiment analysis tools such as SentiStrength and NLTK. However, these tools have been trained on product reviews and movie reviews and, therefore, their results might not be applicable in the software engineering domain. In this paper we study whether the sentiment analysis tools agree with the sentiment recognized by human evaluators (as reported in an earlier study) as well as with each other. Furthermore, we evaluate the impact of the choice of a sentiment analysis tool on software engineering studies by conducting a simple study of differences in issue resolution times for positive, negative and neutral texts. We repeat the study for seven datasets (issue trackers and Stack Overflow questions) and different sentiment analysis tools and observe that the disagreement between the tools can lead to contradictory conclusions.