When developers describe a software system with multiple models, such as architecture diagrams, deployment descriptions, and source code, these models must represent the system in a uniform way, i.e., they must be and stay consistent . One means to automatically preserve consistency after changes to models are model transformations, of which bidirectional transformations that preserve consistency between two models have been well researched. To preserve consistency between multiple models, such transformations can be combined to networks. When transformations are developed independently and reused modularly, the resulting network can be of arbitrary topology. For such networks, no universal strategy exists to orchestrate the execution of transformations such that the resulting models are consistent. In this article, we prove that termination of such a strategy can only be guaranteed if it is incomplete, i.e., if it is allowed to fail to restore consistency for some changes although an execution order of transformations exists that yields consistent models. We propose such a strategy, for which we prove termination and show that and why it makes it easier for users of model transformation networks to understand the reasons whenever the strategy fails. In addition, we provide a simulator for the comparison of different execution strategies. These findings help transformation developers and users in understanding when and why they can expect the execution of a transformation network to terminate and when they can even expect it to succeed. Furthermore, the proposed strategy guarantees them termination and supports them in finding the reason whenever it is not successful.

Abstract When using multiple models to describe a (software) system, one can use a network of model transformations to keep the models consistent after changes. No strategy exists, however, to orchestrate the execution of transformations if the network has an arbitrary topology. In this paper, we analyse how often and in which order transformations need to be executed. We argue why linear execution bounds are too restrictive to be useful in practice and prove that there is no upper bound for the number of necessary executions. To avoid non-termination, we propose a conservative strategy that makes execution failures easier to understand. These insights help developers and users of transformation networks to understand under which circumstances their networks can terminate. Additionally, the proposed strategy helps them to find the cause when a network cannot restore consistency.

During the development of large software-intensive systems, developers use several modeling languages and tools to describe a system from different viewpoints. Model-driven and view-based technologies have made it easier to define domain-specific languages and transformations. Nevertheless, using several languages leads to fragmentation of information, to redundancies in the system description, and eventually to inconsistencies. Inconsistencies have negative impacts on the system’s quality and are costly to fix. Often, there is no support for consistency management across multiple languages. Using a single language is no practicable solution either, as it is overly complex to define, use, and evolve such a language. View-based development is a suitable approach to deal with complex systems, and is widely used in other engineering disciplines. Still, we need to cope with the problems of fragmentation and consistency. In this paper, we present the Vitruvius approach for consistency in view-based modeling. We describe the approach by formalizing the notion of consistency, presenting languages for consistency preservation, and defining a model-driven development process. Furthermore, we show how existing models can be integrated. We have evaluated our approach at two case studies from component-based and embedded automotive software development, using our prototypical implementation based on the Eclipse Modeling Framework.

Multi-view environments provide different views of software systems optimized for different stakeholders. One way of ensuring consistency of overlapping and inter-dependent information contained in such views is to project them “on demand” from a Single Underlying Model (SUM). However, there are various ways of building and evolving such SUMs. This paper presents criteria to distinguish them, describes three archetypical approaches for building SUMs, and analyzes their advantages and disadvantages. From these criteria, guidelines for choosing which approach to use in specific application areas are derived.

Current automotive trends, such as autonomous and connected driving, are mainly enabled by embedded software that is deployed on a network of several, often more than one hundred, electronic control units. These software parts are responsible for many complex tasks concerning safety, comfort, energy management, and vehicle dynamics. Currently, they are deployed to the units at the end of the assembly line. Although a new software baseline of electronic control units is released in regular terms, normally six months, updates during after-sales are mostly conducted only in urgent cases, such as recall campaigns. Upcoming over-the-air services will enable more frequent updates to fix bugs and add new functionality. The possible alternatives of engines, chassis, and customer wishes lead to a high number of existing vehicle variants, so that the management of releases and configurations becomes more complex and costly. In a survey, we asked participants from different automotive institutions about the current state of practice, and the challenges they face during release development and management. This paper presents and discusses the main results of this survey: We have identified that field updates will be deployed more frequently in the future, and that over-the-air communication is an efficient way to realize them. The reported main update reasons are bug fixes and function improvement. However, the shortening release and update cycles, the increasing number of variants, and the multidisciplinarity in the automotive field are major challenges requiring suitable processes, methods, and tools to achieve software that operates correctly.

Models are used in software engineering to describe parts of a system that are relevant for the computation of specific analyses, or the provision of specific functionality. Metamodeling languages such as Ecore make it possible to realize analyses and functionality with model-driven technology, such as transformation engines. If models conform to a metamodel that was expressed using Ecore, numerous Eclipse-based tools can be reused to directly analyze, display, or transform models. In many software projects, models are, however, realized with objects of plain-old Java classes rather than an explicit metamodel, so these popular toolscannot be used.In this new ideas paper, we present an Ecoreification approach, which can be used to automatically extract Ecore-conforming metamodels from Java code, and a code generator that combines the benefits of both worlds. The resulting code can be used exactly as before, but it also uses the modeling infrastructure and implements all interfaces for Ecore-based tooling. This way, arbitrary non-standard models can be displayed and modified, for example using graphical Sirius editors, or transformed with well-proven transformation languages, such as QVT-O or ATL.