Constraint-based run-time state migration for live modeling

Abstract

Live modeling enables modelers to incrementally update models as they are running and get immediate feedback about the impact of their changes. Changes introduced in a model may trigger inconsistencies between the model and its run-time state (e.g., deleting the current state in a statemachine); effectively requiring to migrate the run-time state to comply with the updated model. In this paper, we introduce an approach that enables to automatically migrate such runtime state based on declarative constraints defined by the language designer. We illustrate the approach using Nextep, a meta-modeling language for defining invariants and migration constraints on run-time state models. When a model changes, Nextep employs model finding techniques, backed by a solver, to automatically infer a new run-time model that satisfies the declared constraints. We apply Nextep to define migration strategies for two DSLs, and report on its expressiveness and performance. CCS Concepts • Software and its engineering → Domain specific languages; Software prototyping; • Theory of computation → Programming logic;

Bacatá: Notebooks for DSLs, Almost for Free

“…However, no attention has been paid from the language engineering point of view. There is some work about interactive DSL usage, e.g., domain-specific debuggers [3] and live DSLs [54,68,70].…”

Live modeling in the context of state machine models and code generation

“…As a result, it becomes much easier for modellers to explore the design space of the system they are developing. This not only eases the development of complex software-intensive systems, but also facilitates learning modeling languages and has the potential to improve the quality and efficiency of the development process [85,90].…”

“…In case if the most recently active execution state has been removed during the live modeling session, LMP communicates with the external application to select the next execution state. The external application can select the next state via interaction with the user (our prototype supports this) or apply heuristics and other techniques to select the next execution state (e.g., [85]). We argue that the selection of the next state via communication with the user is simpler and better than other possible solutions since, during the development, it is reasonable to assume that the user is familiar with the model and can select a suitable state.…”

“…Often, a form of live programming is supported by several existing programming languages and Integrated Development Environments (IDEs) (e.g., [35,58,59,65,74]), and its benefits and utility are discussed in several studies (e.g., [16,53,56]). Inspired by this line of work, some efforts [85,88,90] have recently been made towards live modeling, i.e., the application of the changes to the models while they are being executed. However, they only have focused on the support of live modeling in the context of model interpretation (when models are executed by interpretation), and no work supports live modeling when the models are executed by code generation into general programming languages.…”

“…(3) Inconsistent runtime state. As discussed in [85], some changes such as removing the active state of a state machine can invalidate its runtime state. Mechanisms to recover from or even prevent these inconsistencies require a deep understanding of the code generation process and may be challenging to implement.…”