=Paper=
{{Paper
|id=Vol-3250/fpvmpaper1
|storemode=property
|title=Optimistic Versioning for Conflict-tolerant
Collaborative Blended Modeling
|pdfUrl=https://ceur-ws.org/Vol-3250/fpvmpaper1.pdf
|volume=Vol-3250
|authors=Joeri Exelmans,Jakob Pietron,Alexander Raschke,Hans Vangheluwe,Matthias Tichy
|dblpUrl=https://dblp.org/rec/conf/staf/ExelmansPRVT22
}}
==Optimistic Versioning for Conflict-tolerant
Collaborative Blended Modeling==
https://ceur-ws.org/Vol-3250/fpvmpaper1.pdf
Optimistic Versioning for Conflict-tolerant
Collaborative Blended Modeling
Joeri Exelmans1 , Jakob Pietron2 , Alexander Raschke2 , Hans Vangheluwe1 and
Matthias Tichy2
1
Department of Computer Science, University of Antwerp – Flanders Make, Antwerp, Belgium
2
Institute of Software Engineering and Programming Languages, Ulm University, Ulm, Germany
Abstract
Optimistic versioning is a key component in supporting collaborative workflows. Text-based versioning
has been widely adopted for versioning code, but in model-driven engineering, dealing with visual
concrete syntaxes, new methods are required. In the case of blended modeling, a mixture of both textual
and visual syntaxes, concurrently editable and synchronizable, introduces additional challenges.
We propose a type of operation-based versioning to record not only user edits, but also bi-directional
change propagations between concrete and abstract syntax. This way we can support blended modeling
with layout continuity, and flexible handling of missing information (e. g., layout information) when
rendering changes from abstract to concrete syntax. In addition, the proposed versioning approach
enables collaborative conflict resolution by allowing partial conflict resolution, thus deferring a final
resolution.
Keywords
versioning, blended modeling, conflict-tolerant, operation-based
1. Introduction
Model-driven engineering (MDE) has become widely accepted as prime enabler for the creation
of increasingly complex software-intensive systems. In addition to graphical models, various
model representations such as tabular or textual ones are typically used. The flexible use of
different representations (concrete syntax (CS)) for one and the same model (abstract syntax
(AS)) is also called blended modeling. The ability to switch between different representations
allows the user to choose the one that is most useful and efficient for the current task [1].
Complex systems are developed in teams in both asynchronous and synchronous collaborative
environments [2]. Synchronous collaboration has gained importance since the Corona pandemic,
where developers who normally develop models in the same room, e. g. on whiteboards, were
forced to use (online) tools for collaboration [3].
In addition to the complexity of concurrency in (a)synchronous collaboration (i.e. branching,
merging, and dealing with conflicts), an orthogonal problem of blended modeling is the challenge
of (multi-)CS and AS synchronization. For instance, there may be concurrency on the same
FPVM 2022: 2nd International Workshop on Foundations and Practice of Visual Modeling, July 4–8, 2022, Nantes, France
$ joeri.exelmans@uantwerpen.be (J. Exelmans); jakob.pietron@uni-ulm.de (J. Pietron);
alexander.raschke@uni-ulm.de (A. Raschke); hans.vangheluwe@uantwerpen.be (H. Vangheluwe);
matthias.tichy@uni-ulm.de (M. Tichy)
0000-0002-6916-5140 (J. Exelmans); 0000-0001-8308-6636 (J. Pietron); 0000-0002-6088-8393 (A. Raschke);
0000-0003-2079-6643 (H. Vangheluwe); 0000-0002-9067-3748 (M. Tichy)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
concurrent
Legend
visual
merge creation
CS
deletion
render
initial version add rountangle remove rountangle no conflict
parse
AS :State :State :State :State
parent merge parent
:State :State
parse
initial version add state, parent link remove state conflict (require-delete)
render
merge
textual
state {} state {}
CS
initial version (omitted from example) erase text (omitted from example)
Figure 1: Running example: Blended modeling scenario with concurrent user edits
or on different CSs that are being synchronized (see Figure 1 and Section 2). Another issue of
blended modeling is that of missing information when switching between CS representations.
For example, if an element is added in textual syntax, the position of the new corresponding
element in a graphical syntax remains unknown.
Versioning systems for “code” (e.g. git [4], SVN [5]) are only suited for recording textual CS.
Model versioning systems attempt to overcome this limitation by recording, comparing and
merging instead at the level of the AS. Only a single (visual) CS is assumed to exist, with a 1:1
mapping between CS and AS elements. This hinders support for blended modeling.
To overcome this limitation, we propose to combine operation-based versioning with incre-
mental bi-directional change propagation to enable (a) arbitrary mappings between CS and AS,
with traceability between CS and AS, (b) blended modeling with layout continuity and flexible
handling of missing (layout) information, and (c) reuse of CS editing environments for different
languages. Additionally, as part of our operation-based versioning approach, we propose a new
way to persist merge conflicts, to allow recording of the steps taken in conflict resolution.
Our approach should not be confused with projectional editing [6], where CS operations
directly impact the AS without using a parser. On the contrary, we allow arbitrary CS/AS
mappings, increasing the flexibility for the modeler and ultimately the usability of the modeling
environment [7, 8].
The remainder of the paper is structured as follows. In Section 2, we introduce a running
example that is used to illustrate our proposed solution presented in Section 3. Section 4
discusses related work and Section 5 concludes with an outlook on future work.
2. Running Example
To illustrate our approach, we introduce a (visual) CS and AS for a very limited subset of
the Statecharts formalism. On the CS side, we have 2D drawings of rountangles (rounded
rectangles) with geometries. On the AS side, we can have State objects, between which a
“parent” association exists (every State can have 1 parent). The correspondence relation between
CS and AS is as follows: There exists a one-to-one mapping between rountangles and State
objects, and whenever a rountangle is geometrically inside another, a parent link between their
Language-independent components Language-specific components Legend
depends on
Correspondence Explained in
depends on AS Metamodel
Visual CS Editor Versioning Data Structure Metamodel this paper
depends on depends on
Visual CS History Graph Future work
Metamodel Parser Renderer
Dependency Graph
Textual CS Editor synchronize
read append invokes invokes
Textual CS
Metamodel Collaboration Service
synchronize
Figure 2: “Big picture”: A possible architecture
corresponding State objects must exist. Additionally, we assume that there is a textual CS, that
we do not describe here as it does not add additional insight.
Figure 1 shows evolving CS and AS models. Initially, we have a version 𝑀𝐶𝑆𝑉 of a visual CS
model with a single rountangle, 𝑀𝐴𝑆 of the corresponding AS model with a single State, and
𝑀𝐶𝑆𝑇 the corresponding textual CS model. Then, concurrently, a change happens to the visual
and textual CS models. In the visual model, an inner rountangle is added (producing 𝑀𝐶𝑆 ′
𝑉
)
and, concurrently, in the textual model, some text is erased (producing 𝑀𝐶𝑆𝑇 ). Both changes
′′
could be propagated (parsed) to the AS, and subsequently rendered to the other CS. How do we
represent these changes, and how do we merge them? We intuitively understand that there will
be a merge conflict, at least at the level of the AS: a State object is being deleted, while at the
same time, it is the target of a newly created parent link.
There may be many meaningful ways to resolve such a conflict, but this is not our focus
here. In this paper the main focus is on recording (concurrent) changes and (concurrent) change
propagations, on and between CS and AS.
Note that in the remainder of this paper, we assume that text removal in 𝑀𝐶𝑆 ′′
𝑇
has already
been parsed to produce 𝑀𝐴𝑆 . This way, we can focus on the visual CS and the AS, which are
′′
sufficient to explain bi-directional change propagation (the main building block of blended
modeling), combined with concurrency.
3. Solution
We introduce a set of components that can become part of a collaboration architecture. Their
role in a possible architecture is shown in Figure 2.
We explicitly distinguish between language-specific and language-independent components.
In our approach, CS and AS are separate, evolving models, each conforming to their own
metamodel, as proposed by Van Tendeloo [9]. AS metamodels will always be language-specific,
e.g. specific to Statecharts. CS metamodels (and their editors) will often be language-independent.
For instance, a metamodel for vector graphics drawings may serve as a CS meta model for both
Statecharts and Petri Nets. Users only interact directly with a model through a CS. Obviously,
the definition of a mapping between CS and AS will be language-specific. In our approach, this
mapping consists of a correspondence metamodel, and a parser and renderer function. We will
explain these concepts, and specify an interface for parser and renderer functions.
The language-independent component collaboration service is left underspecified. Among its
Rountangle 1 CorrState 1 State
parent
0..1
2 2 2
1
1
CorrParent
Geometry
+ x: float + constraint: "no parent link cycles"
+ y: float 2
+ width: float
+ height: float
+ constraint: "the parent link referred to by CorrParent must connect the
2 States referred to by the same CorrParent"
Figure 3: Running example: Concrete syntax, abstract syntax and correspondence metamodels
many tasks is synchronization of CS editors with evolving CS models, (networked) synchro-
nization between collaborators, and synchronization between CS and AS models. For the latter,
it invokes the parser and renderer functions. This service uses the versioning data structure to
record the edit history of models. We will explain this component, and why it is especially well
suited for blended modeling.
The components presented in this paper are deployment-independent. For instance, the
versioning data structure could be deployed centrally or decentrally.
3.1. Incremental parsing and rendering
A change to a CS may cause corresponding changes to the AS. Change propagation from CS
to AS is called parsing. Subsequently, this change to the AS may cause changes to other CSs.
Change propagation from AS to CS is called rendering 1 .
Parsing and rendering must happen incrementally for several reasons: The first reason is
performance (not having to parse/render from scratch after every change). The second reason is
layout continuity when rendering a visual update (not regenerating a new layout from scratch,
which would be confusing to users familiar with an existing layout). The third reason is that in a
multi-user collaboration scenario, propagating concurrent changes must cause new concurrent
changes (instead of new concurrent models), that can be merged accurately and efficiently.
3.2. Correspondence model
The user only interacts with a model through a CS, so any information (e. g., inconsistencies)
from the AS or semantic level must also be visualized in the CS. CS and AS can relate to each
other in nontrivial ways, and inferring this information a posteriori would be complex, and non-
deterministic (more than one solution). We therefore persist traceability information between
CS and AS elements, and keep it up-to-date, every time changes are propagated.
We persist traceability information between one CS and one AS model in a correspondence
model, an idea taken from triple graph grammars (TGGs) [10]. For any pair of CS and AS
metamodels that can be synchronized, a correspondence metamodel must be defined. This
1
Van Tendeloo uses the terms “comprehension” and “perceptualization” instead of “parsing” and “rendering”,
resp. We find “parsing” and “rendering” more intuitive.
Legend
conforms to
parent version
contains
initial
user-edited model
version
parsed / rendered
merged
Figure 4: Running example: Edit history of CS, AS and Correspondence models
metamodel contains all types of the CS and AS metamodels that it relates to, and also the
different correspondence object types, that associate CS to AS types. At the instance level, a
correspondence model includes one CS and one AS model (it acts as an “overlay” on a (𝐶𝑆, 𝐴𝑆)
model pair), and a set of correspondence objects between their elements.
Running example: Figure 3 shows the metamodels (MM) for “the AS of the CS” (𝑀 𝑀𝐶𝑆𝑉 ,
in blue), the AS (𝑀 𝑀𝐴𝑆 , in red) and the correspondence (𝑀 𝑀𝐶𝑜𝑟𝑟 ). The correspondence
MM includes the elements of the CS and AS MMs, and defines two correspondence object
types (CorrState and CorrParent). CorrState relates one CS rountangle to one AS State, and
CorrParent relates two CS rountangles with geometrical enclosure to a parent link between
their corresponding AS States.
Note that although we adopt some ideas from TGGs, we do not require change propagation
rules to be specified as TGGs - our approach is neutral with respect to rule specification, and
rules may even be specified imperatively.
3.3. Persistence of (propagated) changes
Instances of CS, AS, and correspondence models evolve. We rely on an underlying versioning
system (explained in Section 3.4) to persist every change in each of these models (operation-
based versioning [11]). A change may be the effect of an edit operation, or a propagated change
(ultimately traceable to an edit operation). Changes can be replayed, so in essence, after every
change, a permanent and immutable version is created.
Running example: Figure 4 shows the three metamodels from Figure 3 at the top. Below, we
see a history graph of the model versions from Figure 1, and their conformance to the meta-level.
We saw that 𝑀𝐶𝑆 ′
𝑉
and 𝑀𝐴𝑆 ′′ were produced by concurrent user edits. In our history graph,
we simply record these model versions, and the relation to their parent version (𝑀𝐶𝑆𝑉 and
𝑀𝐴𝑆 , respectively). Parsing and rendering only produces new model versions. Parsing 𝑀𝐶𝑆 ′
𝑉
produces 𝑀𝐴𝑆 ′ and 𝑀 ′
𝐶𝑜𝑟𝑟 , and rendering 𝑀𝐴𝑆 produces 𝑀𝐶𝑆𝑉 and 𝑀𝐶𝑜𝑟𝑟 . All pairs (𝑀𝑥 , 𝑀𝑥 )
′′ ′′ ′′ ′ ′′
are concurrent, and when merged, produce model 𝑀𝑥′′′ (with 𝑥 ∈ {𝐶𝑆𝑉 , 𝐴𝑆, 𝐶𝑜𝑟𝑟}).
We will now explain our versioning approach in more detail. We will see what precisely
makes up a model version, how we persist changes, how we relate changes to CS and AS to
each other, and how we detect conflicts.
<> 1 type
DependencyKind Dependency
produces
delete Element Conflict
require 0..*
depends on 0..* 0..*
update 0..*
0..*
Delta DependencyGraph
0..* 2
1..*
1 0..* 0..*
HistoryGraph Version parent
0..*
Figure 5: Metamodel of the versioning data structure
3.4. Versioning Data Structure
In this section, we present a new and application-agnostic versioning approach. Our approach
can be classified as operation-based according to Brosch et al. [11], meaning that we persist
changes between versions, instead of persisting snapshots of versions. Snapshots can be
reconstructed by replaying changes. By persisting changes, we do not have to perform diffing,
a complex and error-prone process. Persisting changes also enables persisting traceability
information between propagated changes and user edits, which is crucial in order to support
incremental parsing and rendering.
Our versioning approach consists of two data structures, called History Graph and Delta
Graph. We will first explain the Delta Graph, which consists of deltas and dependency links
between them.
Deltas. A delta (colored in green) records a change to a model. A delta may be caused by
a user edit, or a propagated change (model synchronization). We only record the effect of the
change (i. e., atomic CRUD operations on model elements), as opposed to the cause (e.g. the edit
command). Rcording the cause as well may have advantages for edit history comprehensibility
and analysis [12, 13], but this is not our focus. Deltas are transactional, meaning that they are
either fully applied to the model, or not at all.
Dependencies. Deltas can depend on the effect of other deltas. We persist these dependencies
between deltas in a directed, acyclic and append-only Dependency Graph in order to efficiently
detect conflicts between deltas, as we will discuss later. Dependencies can be of three different
types: update, require, and delete.
Figure 6 shows the Dependency Graphs for CS, AS, and correspondence of our running
example. Delta 𝑐𝑠1 results in the creation of the outer rountangle. Further, there is delta 𝑐𝑠2 ,
that creates the inner rountangle. The two deltas do not depend on each other and can, therefore,
be applied to the model in any order, producing 𝑀𝐶𝑆 ′
𝑉
. However, delta 𝑐𝑠3 deletes the outer
rountangle, and in consequence, 𝑐𝑠3 has a delete dependency on 𝑐𝑠1 . If there were a delta
𝑐𝑠𝑥 (not part of our running example - only for illustrative purposes) that resizes the outer
rountangle, it would have an update dependency on 𝑐𝑠1 . The third type, require, occurs when
a delta requires the existence of an element created by an other delta without updating the
required element itself, e.g., when connecting an edge to an element, as in 𝑎𝑠2 .
Concrete Syntax Correspondence Abstract Syntax
: create outer rountangle : create outer rountangle, state : create outer state
: create inner rountangle : create inner rountangle, state : create inner state
: delete outer rountangle + parent link + parent link to outer state
: resize outer rountangle : delete outer rountangle, state : delete outer state
Legend Version Delta Delta contained in version Overlap Dependency Inclusion
Figure 6: Running example: The three dependency graphs of 𝐶𝑆, 𝐶𝑜𝑟𝑟, and 𝐴𝑆 consisting of deltas.
Their effect on the model is listed below. Additionally, the purple layers represent the different versions.
Conflicts. Two deltas that share a dependency on the same model element are conflicting if at
least one of the deltas alters that model element. Conflict types are update-update, update-delete,
and require-delete [11].
Continuing our running example, deltas 𝑐𝑠1 and 𝑐𝑠2 are independent and not conflicting,
because they do not depend on a common delta. In consequence, they can both be part of the
model state without any Conflict as it is the case in 𝑀𝐶𝑆′
𝑉
. However, 𝑐𝑠𝑥 (update geometry of
outer rountangle) and 𝑐𝑠3 (delete outer rountangle) depend concurrently on the same model
element 𝑐𝑠1 and are, consequently, in an update-delete conflict as indicated in orange color in
Figure 6 on the left.
While the Dependency Graph imposes a partial order on the execution of deltas to obtain a
valid state, it does not contain any information about the actual order in which deltas were
added (or omitted, explained later) by different collaborators, altering the model state. Moreover,
we want to be able to point to specific model versions. We therefore introduce the History Graph,
which contains versions and their (partial) order.
Versions. A version (colored in various shades of purple), is a (possibly empty) set of deltas,
that when replayed, produces a model state. In a version, all dependencies of all contained
deltas must also be contained, a property called left-closedness in the theory of Event Structures
[14]. The order of versions is persisted in a History Graph, which is also directed, acyclic
and append-only. Versions refer to their predecessor(s) by parent links, whose semantics are
identical to parent links in git.
Figure 4 of our running example already showed a History Graph, with branching into
:State :State
:State
OR OR
′′′ 𝑋
Figure 7: Running example: Instances of versions and 𝑀𝐴𝑆 and 𝑀𝐶𝑆 𝑉
in a superposition each.
concurrent versions (𝑀𝑥′ and 𝑀𝑥′′ ) and merging (𝑀𝑥′′′ ). Figure 6 visualizes the different versions
as sets of deltas.
The difference between any two versions 𝐴 and 𝐵 is simply a set of added deltas (𝐵 ∖ 𝐴) and
a set of removed deltas (𝐴 ∖ 𝐵). Versions can be trivially merged by taking the union of their
deltas, which preserves left-closedness.
Superpositions. Versions are allowed to contain conflicting deltas. This way, conflicting
states are not just temporary, in-memory phenomena during the merge process, but persistent,
which has two advantages: (1) We can record not just the occurence, but also steps taken in
the resolution of the conflict (as a sequence of versions). This may be valueable information.
(2) Conflicts are non-blocking, and the modeler can continue working on non-conflicting parts
of the model.
We use the term superposition for versions containing conflict(s) (reference to quantum
physics), because the version can be interpreted as containing all possible conflict resolutions.
A conflict (= a pair of deltas) is resolved by excluding from the next version at least one of the
conflicting deltas (and its dependants). Possibly a new delta is introduced, replacing both of the
conflicting deltas.
In Figure 6, the version 𝑀𝐴𝑆 ′′′ is in a superposition, because it contains deltas 𝑎𝑠 and 𝑎𝑠 in
2 3
a require-delete conflict. The possible (non-conflicting) versions contained in the superposition
are {𝑎𝑠1 } × {𝑎𝑠2 , 𝑎𝑠3 , 𝑎𝑠𝑛1 , 𝑎𝑠𝑛2 , ...}, where 𝑎𝑠𝑛𝑖 is a new (e.g. manually added) delta that
replaces both conflicting deltas.
Conflicts in versions can be visualized by presenting the effects of non-conflicting deltas in a
side-by-side view. Figure 7 shows 𝑀𝐴𝑆 ′′ and 𝑀 𝑋
𝐶𝑆𝑉 in their the superposition.
3.5. Parsing and rendering interface
We now define an interface for the parsing and rendering behavior. Parsing and rendering does
not alter models in-place, and their only effect is that they produce new model versions. We
specify their interfaces as pure functions (i.e. functions without side-effects, that only have read
access to their inputs) that return the newly produced model versions. Purity keeps us honest,
forcing us to be explicit about all inputs, and guaranteeing that results are repeatable, which
has benefits in distributed environments: For instance, in live collaboration on the same CS
model, all users could parse the model locally (to reduce latency), while guaranteeing that their
results are identical.
In order to parse incrementally, the parsing and rendering functions need access to the
most recent correspondence model, and to the respective CS or AS changes. As output, a new
correspondence model is produced, which includes a new AS or CS model, respectively.
Running example: In our example, the inputs and outputs are as follows:
′ ′ ′
𝑝𝑎𝑟𝑠𝑒(𝑀𝐶𝑜𝑟𝑟 , 𝑑(𝑀𝐶𝑆𝑉 , 𝑀𝐶𝑆𝑉
)) = (𝑀𝐶𝑜𝑟𝑟 , 𝑀𝐴𝑆 )
′′ ′′ ′′
𝑟𝑒𝑛𝑑𝑒𝑟(𝑀𝐶𝑜𝑟𝑟 , 𝑑(𝑀𝐴𝑆 , 𝑀𝐴𝑆 ), *) = (𝑀𝐶𝑜𝑟𝑟 , 𝑀𝐶𝑆 𝑉
)
where 𝑑 is the difference (i.e. added, removed elements) between two model versions, which
we can easily compute from our deltas. In the rendering function, the asterisk * denotes the
possibility of having additional parameters, which we will motivate in the next section.
The types of parsing errors that can occur are specific to both CS and AS, so we feel that they
should be defined on the level of the correspondence metamodel. When a parsing error occurs,
an object describing the error should be created in the returned correspondence model.
3.6. Dealing with missing information
Rendering is usually non-deterministic in the sense that an AS model can be mapped correctly
onto many CS models, due to missing information (e.g. about layout). An automated rendering
function can however only produce a single result, which may not always match the user’s
intention (which ultimately remains unknown to the computer). Therefore, we believe we must
support human interaction in rendering. We see several complementary ways to support this.
First, the rendering function could have additional input parameters, such as a random seed or
a layout heuristic to optimize, that tweak the result. We could further present a number of pre-
rendered solutions to choose from, based on frequently chosen parameter values. Furthermore,
after rendering, the user can make manual improvements in the CS model. Perhaps a feature in
the CS editor to “freeze” the AS (guaranteeing that the user cannot accidentally alter the AS
while altering the CS) could be beneficial here. This would be easy to implement since we know
when a CS change causes a AS change. Finally, by relying on versioning to record everything,
changes do not have to be rendered (or parsed) immediately. For instance, in a scenario where a
Statechart is being edited through a textual syntax, (interactively) rendering the visual syntax
may be postponed until the visual syntax is actually opened. In the end, empirical study should
point out preferred workflows. Our work can become a basis for such study.
4. Related Work
For space reasons, we limit ourselves in the following to model versioning approaches. A
comprehensive overview of this topic by Brosch et al. can be found in [11]. Various (overlapping)
definitions of conflicts and/or inconsistencies are given in the literature. Mens [15] distinguishes
syntactic, structural, and semantic conflicts, but also calls all of them inconsistencies. Taentzer et
al. provide in [16] a precise formal definition of conflicts based on graph theory. They introduce
the terms state-based and operation-based conflict (not to be mixed up with state-based vs.
operation-based versioning approaches). Our definition of conflict matches the latter.
Brosch et al. present in [17, 18] a taxonomy of conflicts together with a visualization of the
different conflicts (conflict diagram). In this taxonomy, conflicts are either “overlapping changes”
(competing changes, similar to our “conflicts”) or (constraint) “violations”. The overall approach
is based on a tight coupling between AS and CS, but is extensible with language-specific features.
In the graph transformation rules applied for conflict detection and resolution, only the elements
of the AS are considered and also only (abstract) elements of the conflict diagram are generated.
Layout problems arising during the rendering process of the conflict diagram are partially solved
using simple heuristics preserving layout continuity. Layout conflicts in the original model
are only handled in the simplest way by just preserving the layout of the merging user. More
complex layout problems are not considered (and even cannot due to the restriction to the level
of AS).
In contrast to this approach, we explicitly distinguish between CS and AS and thus, are able
to detect and handle conflicts more precisely. In addition, due to our loose coupling of CS and
AS via a correspondence model, we directly support blended modeling environments which
is not the case in the AMOR project [19]. The proposed “conflict-tolerant merging of models”
[13] by Wieland et al. is enabled by design in our approach including the information about
“how this conflict was resolved and who was responsible for the resolution decision” [13]. The
persistence of all (conflicting) deltas together with meta-information of the delta author fulfills
this requirement.
In [9], van Tendeloo et al. present a more flexible framework for collaborative model devel-
opment with a clear separation of CS and AS, each corresponding to their own metamodel. Our
underlying idea of a flexible, language-independent modeling environment that supports the
indeterminacy needed for blended modeling is based on this work [20]. The problem with van
Tendeloo’s framework is that it leaves open when and how the synchronization of CS and AS
can and should be done. Our approach attempts to bridge this gap.
The work of Pietron et al. [12] presents an operation-based versioning system propagating
user-performed edit operations. Compared to the approach in the course of this paper, their
work focuses mainly on the AS and does not support multiple CS and their synchronization.
Some CS-related operations, such as updating the layout of an element, are supported but lack
a clear distinction from AS-related operations.
5. Conclusion
We presented a set of components and interfaces for collaborative modeling environments
supporting CS reuse and blended modeling through loose CS/AS coupling, and bi-directional
synchronization. By explicitly versioning CS, AS, and their correspondence, we can distinguish
between conflicts on each of these levels, and synchronizations can happen asynchronously or
even be postponed, which is especially useful when dealing with missing information while
rendering. By allowing versions with unresolved conflicts to be persisted, we support deferred
resolution of merge conflicts in a collaborative way, as suggested by Wieland et al. [13].
Currently, we are working on a formal, yet abstract description of a conflict and inconsistency
detection algorithm and its demonstration in a prototypical web-based implementation of such
a modeling environment. Another future research direction is the consideration of multiple
layers between CS and AS with increasing abstraction levels (insideness, connectedness relation,
etc.), to allow even more CS reuse between languages.
Acknowledgments
Author J. Exelmans is an SB PhD fellow at FWO (1S70622N). Author J. Pietron is partly funded
by the project GENIAL!, which is partly funded by the German Federal Ministry of Education
and Research (BMBF) within the research programme ICT 2020 (reference number: 16ES0875).
References
[1] F. Ciccozzi, M. Tichy, H. Vangheluwe, D. Weyns, Blended Modelling - What, Why and
How, in: 2019 ACM/IEEE 22nd International Conference on Model Driven Engineer-
ing Languages and Systems Companion (MODELS-C), 2019, pp. 425–430. doi:10.1109/
MODELS-C.2019.00068.
[2] S. Abrahão, F. Bourdeleau, B. H. C. Cheng, S. Kokaly, R. F. Paige, H. Störrle, J. Whittle,
User experience for model-driven engineering: Challenges and future directions, in:
20th ACM/IEEE International Conference on Model Driven Engineering Languages and
Systems, MODELS 2017, IEEE, 2017, pp. 229–236. doi:10.1109/MODELS.2017.5.
[3] I. David, K. Aslam, S. Faridmoayer, I. Malavolta, E. Syriani, P. Lago, Collaborative model-
driven software engineering: A systematic update, in: 24th International Conference
on Model Driven Engineering Languages and Systems, MODELS 2021, IEEE, 2021, pp.
273–284. doi:10.1109/MODELS50736.2021.00035.
[4] git Version Control System, 2022. URL: https://git-scm.com/, last visited: 10/05/2022.
[5] Apache Subversion, 2022. URL: https://subversion.apache.org/, last visited: 10/05/2022.
[6] T. Berger, M. Völter, H. P. Jensen, T. Dangprasert, J. Siegmund, Efficiency of projectional
editing: A controlled experiment, in: Proceedings of the 24th ACM SIGSOFT International
Symposium on Foundations of Software Engineering (FSE), ACM, New York, NY, USA,
2016, p. 763–774. doi:10.1145/2950290.2950315.
[7] B. Nuseibeh, S. Easterbrook, A. Russo, Making inconsistency respectable in software
development, Journal of Systems and Software 58 (2001) 171 – 180. doi:10.1016/
S0164-1212(01)00036-X.
[8] E. Guerra, J. de Lara, On the Quest for Flexible Modelling, in: Proceedings of the
21th ACM/IEEE International Conference on Model Driven Engineering Languages and
Systems (MODELS), MODELS ’18, ACM, New York, NY, USA, 2018, pp. 23–33. doi:10.
1145/3239372.3239376.
[9] Y. V. Tendeloo, H. Vangheluwe, Unifying model- and screen sharing, IEEE 27th Interna-
tional Conference on Enabling Technologies: Infrastructure for Collaborative Enterprises
(WETICE) (2018) 127–132. doi:10.1109/WETICE.2018.00031.
[10] A. Schürr, Specification of graph translators with triple graph grammars, in: E. W. Mayr,
G. Schmidt, G. Tinhofer (Eds.), Graph-Theoretic Concepts in Computer Science, Springer
Berlin Heidelberg, Berlin, Heidelberg, 1995, pp. 151–163. doi:10.1007/3-540-59071-4_
45.
[11] P. Brosch, G. Kappel, P. Langer, M. Seidl, K. Wieland, M. Wimmer, An Introduction to
Model Versioning, in: M. Bernardo, V. Cortellessa, A. Pierantonio (Eds.), Formal Methods
for Model-Driven Engineering, volume LNCS 7320, Springer, Berlin, Heidelberg, 2012, pp.
336–398. doi:10.1007/978-3-642-30982-3_10.
[12] J. Pietron, F. Füg, M. Tichy, An operation-based versioning approach for synchronous and
asynchronous collaboration in graphical modeling tools, in: L. Iovino, L. M. Kristensen
(Eds.), STAF 2021 Workshop Proceedings, volume 2999 of CEUR Workshop Proceedings,
CEUR-WS.org, 2021, pp. 88–89. URL: http://ceur-ws.org/Vol-2999/fpvmdata4mdepaper3.
pdf.
[13] K. Wieland, P. Langer, M. Seidl, M. Wimmer, G. Kappel, Turning Conflicts into
Collaboration, Computer Supported Cooperative Work (CSCW) 22 (2013) 181–240.
doi:10.1007/s10606-012-9172-4.
[14] G. Winskel, An introduction to event structures, in: J. W. de Bakker, W. P. de Roever,
G. Rozenberg (Eds.), Linear Time, Branching Time and Partial Order in Logics and Models
for Concurrency, School/Workshop, Noordwijkerhout, The Netherlands, May 30 - June 3,
1988, Proceedings, volume 354 of Lecture Notes in Computer Science, Springer, 1988, pp.
364–397. doi:10.1007/BFb0013026.
[15] T. Mens, A state-of-the-art survey on software merging, IEEE Transactions on Software
Engineering 28 (2002) 449–462. doi:10.1109/TSE.2002.1000449.
[16] G. Taentzer, C. Ermel, P. Langer, M. Wimmer, Conflict Detection for Model Versioning
Based on Graph Modifications, in: H. Ehrig, A. Rensink, G. Rozenberg, A. Schürr (Eds.),
Graph Transformations, Lecture Notes in Computer Science, Springer, Berlin, Heidelberg,
2010, pp. 171–186. doi:10/dcjxkr.
[17] P. Brosch, M. Seidl, M. Wimmer, G. Kappel, Conflict visualization for evolving UML models,
J. Object Technol. 11 (2012) 2: 1–30. doi:10.5381/jot.2012.11.3.a2.
[18] P. Brosch, Conflict Resolution in Model Versioning, Ph.D. thesis, Vienna University of
Technology, Vienna, 2012. URL: https://publik.tuwien.ac.at/files/PubDat_208975.pdf.
[19] AMOR — Adaptable Model Versioning, 2009. URL: http://modelversioning.org/, last visited:
10/05/2022.
[20] L. Nachreiner, A. Raschke, M. Stegmaier, M. Tichy, CouchEdit: A Relaxed Conformance
Editing Approach, in: Proceedings of the 23rd ACM/IEEE International Conference on
Model Driven Engineering Languages and Systems: Companion Proceedings (MODELS-C),
ACM, 2020, pp. 1–5. doi:10.1145/3417990.3421401.