Exploring Conflict Reasons for Graph Transformation Systems

Lambers, Leen; Kosiol, Jens; Strüber, Daniel; Taentzer, Gabriele

doi:10.1007/978-3-030-23611-3_5

Cited by 6 publications

(4 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We also anticipate there to be other applications, since there are many other reasons one would want to show confluence up to garbage, such as considering GT systems as computing functions where we restrict the domain [11]. Indeed, one might only be interested in the non-garbage critical pairs themselves, and classification of conflicts [30,31].…”

Section: Discussionmentioning

confidence: 99%

Confluence up to Garbage in Graph Transformation

Campbell¹,

Plump²

2021

Preprint

View full text Add to dashboard Cite

The transformation of graphs and graph-like structures is ubiquitous in computer science. When a system is described by graph-transformation rules, it is often desirable that the rules are both terminating and confluent so that rule applications in an arbitrary order produce unique resulting graphs. However, there are application scenarios where the rules are not globally confluent but confluent on a subclass of graphs that are of interest. In other words, nonresolvable conflicts can only occur on graphs that are considered as "garbage". In this paper, we introduce the notion of confluence up to garbage and generalise Plump's critical pair lemma for double-pushout graph transformation, providing a sufficient condition for confluence up to garbage by non-garbage critical pair analysis. We apply our results in two case studies about efficient language recognition: we present backtracking-free graph reduction systems which recognise a class of flow diagrams and a class of labelled series-parallel graphs, respectively. Both systems are non-confluent but confluent up to garbage. We also give a critical pair condition for subcommutativity up to garbage which, together with closedness, implies confluence up to garbage even in non-terminating systems.

show abstract

Section: Discussionmentioning

confidence: 99%

Confluence up to Garbage in Graph Transformation

Campbell¹,

Plump²

2021

Preprint

View full text Add to dashboard Cite

show abstract

“…We also anticipate there to be other applications, since there are many other reasons one would want to show confluence up to garbage, such as considering GT systems as computing functions where we restrict [15]. Indeed, one might only be interested in the non-garbage critical pairs themselves, and classification of conflicts [20,22].…”

Section: Discussionmentioning

confidence: 99%

Confluence up to Garbage

Campbell

Plump

2020

Graph Transformation

View full text Add to dashboard Cite

The transformation of graphs and graph-like structures is ubiquitous in computer science. When a system is described by graphtransformation rules, it is often desirable that the rules are both terminating and confluent so that rule applications in an arbitrary order produce unique resulting graphs. However, there are application scenarios where the rules are not globally confluent but confluent on a subclass of graphs that are of interest. In other words, non-resolvable conflicts can only occur on graphs that are considered as "garbage". In this paper, we introduce the notion of confluence up to garbage and generalise Plump's critical pair lemma for double-pushout graph transformation, providing a sufficient condition for confluence up to garbage by non-garbage critical pair analysis. We apply our results to language recognition by backtracking-free graph reduction, showing how to establish that a graph language can be decided by a system which is confluent up to garbage. We present two case studies with backtracking-free graph reduction systems which recognise a class of flow diagrams and a class of labelled series-parallel graphs, respectively. Both systems are non-confluent but confluent up to garbage.

show abstract

“…This can be provided directly to the generic concurrent execution engine. -Graph-transformation-based operational semantics runtimes can use conflict analysis [31] to identify pairs of rule applications that are in conflict and must, therefore, not be executed concurrently. This information can be encoded as a set of constraints provided to the generic concurrent execution engine.…”

Section: Concurrency Strategies In the Execution Flow Of The Protocolmentioning

confidence: 99%

A generic framework for representing and analyzing model concurrency

et al. 2023

View full text Add to dashboard Cite

Recent results in language engineering simplify the development of tool-supported executable domain-specific modeling languages (xDSMLs), including editing (e.g., completion and error checking) and execution analysis tools (e.g., debugging, monitoring and live modeling). However, such frameworks are currently limited to sequential execution traces and cannot handle execution traces resulting from an execution semantics with a concurrency model supporting parallelism or interleaving. This prevents the development of concurrency analysis tools, like debuggers supporting the exploration of model executions resulting from different interleavings. In this paper, we present a generic framework to integrate execution semantics with either implicit or explicit concurrency models, to explore the possible execution traces of conforming models, and to define strategies for helping in the exploration of the possible executions. This framework is complemented with a protocol to interact with the resulting executions and hence to build advanced concurrency analysis tools. The approach has been implemented within the GEMOC Studio. We demonstrate how to integrate two representative concurrent meta-programming approaches (MoCCML/Java and Henshin), which use different paradigms and underlying foundations to define an xDSML’s concurrency model. We also demonstrate the ability to define an advanced concurrent omniscient debugger with the proposed protocol. The paper, thus, contributes key abstractions and an associated protocol for integrating concurrent meta-programming approaches in a language workbench, and dynamically exploring the possible executions of a model in the modeling workbench.

show abstract

Exploring Conflict Reasons for Graph Transformation Systems

Cited by 6 publications

References 11 publications

Confluence up to Garbage in Graph Transformation

Confluence up to Garbage in Graph Transformation

Confluence up to Garbage

A generic framework for representing and analyzing model concurrency

Contact Info

Product

Resources

About