=Paper=
{{Paper
|id=Vol-2245/commitmde_paper_4
|storemode=property
|title=Delta-driven Collaborative Modeling
|pdfUrl=https://ceur-ws.org/Vol-2245/commitmde_paper_4.pdf
|volume=Vol-2245
|authors=Maik Appeldorn,Dilshodbek Kuryazov,Andreas Winter
|dblpUrl=https://dblp.org/rec/conf/models/AppeldornK018
}}
==Delta-driven Collaborative Modeling==
https://ceur-ws.org/Vol-2245/commitmde_paper_4.pdf
Delta-driven collaborative modeling
Maik Appeldorn, Dilshod Kuryazov and Andreas Winter
University of Oldenburg
26129 Oldenburg, Germany
maik.appeldorn@uni-oldenburg.de
{kuryazov,winter}@se.uni-oldenburg.de
ABSTRACT Development and maintenance of software models requires a
Model-Driven Engineering has already become a significant means need for collaborative modeling of several collaborators like man-
in software development activities, which is well-suited to design agers, designers, developers, testers, and maintainers in order to
and develop large-scale software systems. Developing and main- accomplish successful results [21]. Several collaborators involved
taining large-scale model-driven software systems entails a need in software modeling apply changes to the shared software models.
for collaborative modeling by a large number of software designers Collaborative modeling approaches have to provide support for
and developers. As the first-class entities of the model-driven engi- communication among collaborators by: change representation for
neering paradigm, software models are constantly changed during storing the histories of the changed model elements, synchroniza-
development and maintenance. Collaborative modeling support tion of the represented model changes, and management of software
for frequently synchronizing model changes between collabora- models and their revisions stored in the repositories. These core
tors is required. Thereby, a solid change representation support for features that collaborative modeling approaches have to provide
model changes plays an essential role for collaborative modeling are also addressed in [18] as the result of a solid and sophisticated
systems. This paper applies a meta-model generic, operation-based literature study.
and textual difference language to existing domain-specific model- Depending on the nature of interaction, collaborative model-
ing tool UML Designer and demonstrates a collaborative modeling ing can be divided into two main forms, namely concurrent and
application – CoMo. It is validated for UML activity diagrams. sequential collaborative modeling [14], [27]:
• Concurrent Collaboration. The essential and widely used sce-
nario of collaborative modeling is the development of software
models in real-time by several collaborators in parallel. The con-
1 MOTIVATION current collaborative modeling is usually dedicated to creating,
Model-Driven Engineering (MDE) has become a popular means for modifying and maintaining the huge, shared and centralized
software development which supports appropriate abstraction con- software models. These changes are synchronized in real-time.
cepts to software development activities. It aims at improving the The real-time collaborative editing approaches are extensively
productivity of software development, maintenance activities, and investigated in textual document writing, e.g., Google Docs [19],
communication among various teams and stakeholders. In MDE, Etherpad [4], Firepad [16], and many more. Unlike textual docu-
software models are the first-class artifacts of software development ment editing, the increased performance of change synchroniza-
rather than the source code implementing the systems. This leads tion matters in collaborative modeling because of the graph-like
to the several main benefits of MDE: the productivity boost, models complex structures of software models. Thus, model changes
become a single point of truth and are automatically kept up-to-date have to be identified continually, represented and synchronized
with the code they specify [24, pp. 9ff]. using very simple notations. Typically, these changes are con-
Software models (e.g. in UML – Unified Modeling Language [32]) stantly detected by listening for users actions on a particular
are the key artifacts in MDE activities. In order to cope with the model instance and produced in form of the small set of changes
constantly growing amount of software artifacts and their complex- contained in Modeling Deltas [26]. Thus, modeling deltas are
ity, software systems to be developed or maintained are usually rather small in real-time collaboration and they are usually not
shifted to abstract forms using the modeling concepts. Software stored, yet synchronized between the parallel working copies
models focus on the most relevant aspects of the problem domain of software models. The real-time synchronization of modeling
to be designed and developed. Simultaneously, software models deltas is enabled by micro-versioning [27].
are the documentation and implementation of the software systems • Sequential Collaboration. Another significant scenario of collabo-
being developed and maintained [24]. rative modeling is sequential collaboration which is also referred
Like the source code of software systems, software models are to as model management in some literature [18]. Sequential col-
constantly evolved and maintained in order to cope with various laboration intends to identify the model differences between the
user changes such as improvements, extensions, and optimization. subsequent revisions of modeling artifacts, store and reuse them
All development and maintenance activities contribute to the evo- when needed. There are several classical source code version
lution of software models. These activities may include creating new control (sequential collaboration) approaches such as Subversion
artifacts, removing existing ones, or/and changing the attributes [8], Git [35], etc. These systems for the source code of software
of existing artifacts. Any type of the aforementioned changes that systems are the best aid in handling development and evolu-
may occur during development and evolution of software models tion of large-scale, complex and continually evolving software
are referred to as model changes. systems. The same support is needed for software models. For
instance, while designing software models in concurrent collab- Concurrent collaboration systems record and synchronize change
oration, collaborators intend to store the correct and complete notifications during collaborative development. Collaborative doc-
revision of their model and open it after a while to continue ument writing systems like Google Docs [19] and Etherpad [4] are
development and maintenance. These model management activi- widely used systems in concurrent document creation and editing.
ties are facilitated by macro-versioning [27]. In macro-versioning, There are also several Web-based modeling tools e.g. GenMyModel
the differences between subsequent model revisions are repre- [9] and Creately [7], which exchange changes over WebSockets.
sented in Modeling Deltas, as well. Modeling deltas consist of the Their core ideas and underlying change representation techniques
larger set of model changes in macro-versioning, whereas they are not explicitly documented. Their modeling concepts and other
represent the small set of model changes in micro-versioning. services are not accessible, making them difficult to study and ex-
In both micro- and macro-versioning scenarios, modeling deltas tend. The collaborative modeling approaches emfCollab [1] and
are the first-class entities and play an essential role in synchronizing Dawn [17] (the sub-component of CDO - Connected Data Objects
the small model changes between the parallel instances of models, [13]) provide collaborative development features for EMF models.
storing/representing model changes in efficient ways, and manag- However, they use custom serialization of changes for synchro-
ing models and their revisions. The both collaborative modeling nization in concurrent modeling. Dawn utilizes standard relational
scenarios might rely on the same underlying change representa- databases to persist models under development.
tion approach to deal with modeling deltas. Therefore, the efficient Sequential collaboration systems such as Git [35], Mercurial [28],
representation of modeling deltas is crucial for both scenarios. Subversion [8] are used for sequential revision control in source
A meta-model generic, operation-based and textual change rep- code-driven software development. There are also sequential collab-
resentation approach entitled Difference Language (DL) for repre- orative modeling systems, e.g., EMF Store [20], SMoVer [3], AMOR
senting modeling deltas in both micro- and macro-versioning was [5] and Taentzer et. al. [36] that are discussed in Section 2.2.
introduced in [26]. A DL-based collaborative modeling infrastruc- For differentiating revisions and calculating differences, most
ture was developed and applied to UML class diagrams in [27]. The of the collaborative systems for source code-driven software de-
proposed DL is meta-model generic, operation-based, modeling velopment use the Myer’s LCS [29] algorithm, which is based on
tool generic, reusable, applicable, and extensible. Moreover, the recursively finding the longest sequence of common lines in the
associated technical support further provides a catalog of supple- list of lines of compared revisions. Software models can also be
mentary services which allow for producing and reusing modeling represented in textual formats using XMI exchange formats, but it
deltas represented by DL. As long as there already are several ad- is commonly agreed that the collaborative approaches for source
vanced model designing tools, this paper applies the DL approach code cannot sufficiently fit to MDE because of the paradigm shift
to Sirius-based [11] domain-specific modeling tool UML Designer between source code- and model-driven concepts [6], [34]. Differen-
[31] which results in the Collaborative Modeling (CoMo) application. tiating the textual lines of the XMI-based software models can not
UML activity diagrams [32] are considered as the domain language provide sufficient information about the changes in associated and
throughout this paper. composite data structures of software models, as well as does not
The remainder of this paper is structured as follows: Section 2 reflect the semantics of changes. As there are already outstanding
investigates existing related approaches in the research domain. collaborative systems for textual documents and the source code
Several characteristics of DL and its collaborative modeling ap- of software systems, MDE also requires support for generic, solid,
plication are defined in Section 3. The core concepts behind the configurable and extensible collaborative modeling applications for
DL-based collaborative modeling are depicted in Section 4 and the their development, maintenance, and evolution.
same section explains the subset of services provided by DL. Sec-
tion 5 explains the CoMo collaborative modeling application of DL.
2.2 Delta Representation Approaches
Section 6 discusses adaptability and extendability of the DL-based
collaborative modeling application. This paper ends up in Section 7 As long as modeling delta representation is a decisively significant
by drawing some conclusions. issue in developing collaborative environments, this section briefly
reviews and classifies some delta representation approaches. The
existing collaborative modeling approaches employ various tech-
2 RELATED APPROACHES niques for model change representation in modeling deltas. Below,
The problem of collaborative modeling and its change represen- the existing approaches are classified and discussed according to
tation is the actively discussed and extensively addressed topic their difference/change representation techniques.
among the research community of software engineering. There The most approaches identify themselves as the operation-based
is a large number of research papers addressing to collaborative difference representation. They usually use basic edit operations
modeling (Section 2.1) and model difference/change representation such as create, delete and change (or similar and more), which is
(Section 2.2). a general concept being relevant to many difference representa-
tion approaches. Regardless of their difference representation tech-
niques, they employ these basic operations only for recognizing
2.1 Collaborative Systems the types of model changes, but information about model changes
This section briefly reviews some collaborative development, doc- is generally stored in various forms as discussed below.
ument editing and modeling approaches in order to derive some Model-based approaches represent modeling deltas using models.
general concepts and principals. Cicchetti et al. [6] introduced a meta-model independent approach
that uses software models for representing model differences con- data set. Thus, the database-based representation approaches may
forming to a difference meta-model. Cicchetti et al. also provides require more implementation effort in identification and reuse of
a service (incl. conflict resolution) to apply difference models to modeling deltas.
differentiated models in order to transform them from one revision Modeling deltas represented in textual forms are the most likely
to another. A fundamental approach to sequential model version to be small, especially well-suited to concurrent collaboration sce-
control based on graph modifications introduced by Taentzer et. nario. The textual modeling deltas are (1) directly executable de-
al. [36] is also used to represent model differences using models. scriptions of model changes; (2) easy to implement; (3) expres-
The approach is validated in Adaptable Model Versioning System sive, yet unambiguous providing necessary knowledge; (4) easy
(AMOR) [5] for EMF models [34]. The major focus of the approach to synchronize with high performance; (5) easy serialization and
is differentiation and merging of software models that serve as the deserialization by textual parser.
main foundations for sequential model version control. Literature review shows that research on modeling delta repre-
Graph-based approaches represent model changes using internal sentation for collaborative modeling is still in its infancy. Consider-
graph-like structures. It is usually similar to model-based represen- ing the aforementioned discussions, this paper requests a textual
tation, but relying on the low-level graph-like structures. A generic difference language (DL) to represent modeling deltas in sequential
approach to model difference calculation and representation using and concurrent collaborative modeling.
edit scripts is introduced in the SiDiff approach [23]. SiDiff consists
of a chain of model differencing processes, including correspon-
dence matching, difference derivation, and semantic lifting [22]. 3 CHARACTERISTICS
SiDiff does not rely on a specific modeling language. The SiDiff’s A meta-model generic, operation-based and textual Difference Lan-
difference calculator algorithm is also utilized by the approach guage (DL) for representing modeling deltas in both micro- and
in this paper to realized its delta calculator service (explained in macro-versioning was introduced in [26]. A collaborative modeling
Section 4.3). infrastructure based on DL was developed and applied to UML
Relational Database-based approaches represent model changes class diagram in [27], which resulted in a tool entitled Kotelett. DL
in classical relational databases. Likely, SMOVER [3] and Dawn further provides a catalog of supplementary services which allow
[17] take advantage of relational databases to store model changes to produce and reuse DL-based modeling deltas. The subset of these
and to persist their models under development and evolution. services delta calculator (change listener feature), delta applier, model
Text-based approaches represent model changes in modeling manager and delta synchronizer are used in developing collaborative
deltas by a sequence of edit operations in the textual forms embed- modeling application in this paper.
ding change-related difference information. An early text-based Several requirements operation-based, meta-model generic, tool
representation approach is introduced by Alanen and Porres [2]. independent, delta-based, completeness, reusability for DL and its
EMF Store [20] is a model and data repository for EMF-based soft- services are described and fulfilled in [25]. Further requirements
ware models. The framework enables collaborative work of several (awareness of content and layout, genericness, supportiveness) for the
modelers directly via peer-to-peer connection providing semantic overall DL-collaborative modeling infrastructure are defined and
version control of models. Dawn [17] and emfCollab [1] use their satisfied in [27].
custom serialization of model changes for synchronizing them be- Since there are already several advanced domain-specific model
tween collaborators. DeltaEcore [33] is a delta language generation designing tools, this paper applies the DL-based collaborative mod-
framework and addresses the problem of generating delta modeling eling infrastructure to Sirius-based [11] domain-specific modeling
languages for software product lines and software ecosystems. tool UML Designer [31]. The UML activity diagram [32] is consid-
This section discusses the existing related approaches based on ered as domain language throughout this paper. Before explaining
the criteria if representation by these approaches can provide small the core application ideas, this section lists several further charac-
modeling deltas for both sequential and concurrent collaborative teristics addressing the adaptability aspect of the approach.
modeling. Besides, there are several approaches focusing only on Meta-model. DL is conceptually a family of domain-specific lan-
some aspects of these collaborative modeling, and are not discussed guages and generic with respect to the meta-models of modeling
in this paper. languages. As long as the modeling concepts of any modeling lan-
The graph- and model-based representations of modeling deltas guage can be recognized by looking at the meta-models of these
are more effective in case of the sequential collaboration and dis- languages, specific DLs for particular modeling languages are gen-
tributed concurrent collaboration. The modeling deltas represented erated by importing their meta-models. Therefore, DL requires the
by models or graphs usually consist of additional conceptual infor- meta-model of a modeling language, in this particular case, the
mation for representing its modeling or graph concepts alongside meta-model of UML activity diagrams. DL supports the follow-
actual change information. Thus, the model- and graph-based mod- ing characteristics to apply the DL-based collaborative modeling
eling deltas might not be as small (micro) as text-based modeling infrastructure to the modeling language:
deltas. Modeling deltas have to be as small as possible to achieve • DL Generation. In order to apply the DL-based collaborative
higher performance (by rapid synchronization of modeling deltas) modeling infrastructure to a particular domain-specific language
in concurrent collaborative modeling in real-time. During the evolu- which is defined by its appropriate meta-model, the DL generator
tionary life-cycle, if all difference information is stored in a database, service (Section 4.3) generates a specific DL from the meta-model
the database might become complex and large with an associated of a potential modeling language, UML activity diagram. Then,
the modeling deltas can be represented in terms of DL on the developing visual modeling editors based on EMF. The ActivityNode
instance models conforming to that modeling language. and ActivityEdge of the content part are connected to the Node and
• Service Adaptation. DL supports several potential supplemen- Edge of the layout part through the DNode and DEdge artifacts of
tary services (Section 4.3) for extending the application areas the Sirius odesign notation.
of DL. These services are capable of operating on the DL-based This way of designing meta-models allows for using the same col-
modeling deltas, e.g., calculating, applying, synchronizing, and laborative modeling environment for different modeling contents.
managing modeling deltas. For applying the DL-based collab- The complete meta-model is used for creating overall collaborative
orative modeling infrastructure to domain-specific tool UML modeling application explained in Section 5.
designer, delta calculator and delta applier services have to be
adapted. The other services remain unchanged.
4.2 Motivating Example
These characteristic are addressed in Section 4 to apply the DL-
based collaborative modeling infrastructure to design UML activity In order to express how DL is applied to change representation
diagrams in the UML Designer tool. for activity diagrams, this section presents a simplified example
for the DL-based change representation in modeling deltas. A very
simple UML activity diagram is chosen as a running example to
4 APPROACH
apply the DL approach. Figure 2 depicts three subsequent revisions
The DL-based collaborative modeling infrastructure considers model namely Rev_1, Rev_2 and Rev_3 of the same UML activity diagram
changes as the first-class entities for supporting concurrent collab- describing an "Ordering System" example. All model revisions
oration by micro-versioning and sequential collaboration by macro- conform to the same meta-model shown in Figure 1. Figure 2 further
versioning. Thus, first of all, DL aims at representing model changes depicts two concurrent copies of the latest revision, in this case,
in modeling deltas in efficient ways. Rev_3. Two designers, namely Designer_1 and Designer_2 are
DL is conceptually a family of domain-specific languages for working on these parallel copies.
representing model changes. A specific DL is derived from the meta- Globally Unique Identifiers. According to the NamedElement
model of a modeling language. Since this paper applies the DL-based class of the meta-model in Figure 1, each modeling artifact has
collaborative modeling infrastructure to designing UML activity an attribute named id. In order to identify modeling artifacts and
diagrams in UML Designer, the approach requests the meta-model to represent referenced changes in modeling deltas, this identifier
of activity diagram as initial prerequisite to generate a specific attribute is used in modeling delta operations. Assigning model-
DL. Thereafter, the relevant DL services have to be adapted to be ing artifacts to globally unique identifiers allows to identify and
capable of handling new modeling languages in the new model keep track of the modeling artifacts of evolving software models
designing tool. over time. With unique identifiers, inter-delta (i.e., predecessor and
Section 4.1 depicts the substructure of the UML activity diagram successor) and delta-model references can easily be detected. The
meta-model. Section 4.2 exemplifies a simplified running exam- inter-delta references allow for tracing any particular modeling
ple for the DL-based change representation. Section 4.3 explains artifact by detecting the predecessor and successor artifacts of an
a subset of supplementary DL services required for applying col- initial modeling artifact. The delta-model references are used to
laborative modeling and how they are adapted to be handy in this refer to modeling artifacts from modeling deltas in applying model-
particular case. ing deltas to software models by the DL applier service (explained
in Section 4.3).
4.1 Meta-Model Model Changes. In the first revision, the model consists of one
The modeling concepts of any modeling language can be recognized Opaque Action named "Receive" as well as Initial Node and Final
by inspecting the meta-model of that language. Thus, a specific Node. All modeling artifacts are connected by Control Flows. While
DL for UML activity diagram is generated by the DL generator ser- evolving from the first revision to the second, the following changes
vice (explained in Section 4.3) importing the UML activity diagram are made on the model: Fork Node, Join Node, two Opaque Actions
meta-model. Then, the model changes in modeling deltas can be named "Fill Order" and "Send Invoice" are created, the target
represented in terms of DL on the instance activity diagrams. How- end of the control flow g5 is reconnected to the Fork Node, the name
ever, the DL generator is generic with respect to the meta-models of the Opaque Action g2 is changed, and several control flows are
of modeling languages. created connecting these nodes. The model again evolves into the
Figure 1 depicts the substructure of the UML activity diagram third revision Rev_3 after making the following changes: the target
meta-model that is used throughout this section as a running exam- end of the control flow g5 is reconnected to the Opaque Action g7,
ple. The meta-model is separated into two parts by a dashed line. the target end of the control flow g12 is reconnected to the Activity
Below the line, it depicts the content part (i.e., abstract syntax) which Final Node. The nodes Fork Node, Join Node, Opaque Action "g8"
is adapted from the standard UML activity diagram meta-model for and the control flows g10, g11, g13, g14 are deleted.
EMF (Eclipse Modeling Framework) [34]. In graphical modeling, In the third, last revision, the model is then being further de-
each modeling object has design information such as color, size, veloped by two designers concurrently. Designer_1 changes the
and position, also called layout information. Above the dashed line, names of the Opaque Actions g2 and g7 from "Receive Order" and
Figure 1 portrays the layout part (i.e., concrete syntax). The layout "Fill Order" to "Receive Orders" and "Fill Orders", respec-
part of the meta-model depicts the substructure of Graphical Mod- tively. These changes are then sent to the other instance in form
eling Framework (GMF) notation [12] which supports notation for of the DL-based modeling delta (Figure 6). On the other instance,
Layout Part
Content Part
Figure 1: UML Activity Diagram Meta-model
Designer_2 creates a new Opaque Action named "Close Order". order, i.e., application of the backward deltas to models transforms
The same designer creates one Control Flow g16 and reconnects models into the earlier revisions. For instance, application of the
the target end of the control flow g12 from the Activity Final Node backward delta in Figure 3 to Rev_3 results in Rev_2.
g3 to the newly created node g15. These changes are then sent
to the other instance, Designer_1 is working on, as the DL-based 1 g6 = createForkNode ( ) ;
modeling delta (Figure 7). 2 g8 = createOpaqueAction ( " Send I n v o i c e " ) ;
Modeling Deltas in Sequential Collaboration. In sequential 3 g9 = createJoinNode ( ) ;
collaboration (cf. Subversion [8], Git [35]), the differences between 4 g10 = createControlFlow ( g6 , g7 ) ;
subsequent revisions are usually identified and represented in re- 5 g11 = createControlFlow ( g6 , g8 ) ;
verse order, i.e., they represent changes in the backward deltas 6 g13 = createControlFlow ( g8 , g9 ) ;
[26]. Because these systems intend to store differences as directly 7 g14 = createControlFlow ( g9 , g3 ) ;
executable forms that is more practical in retrieving the earlier 8 g5 . changeTarget ( g6 ) ;
revisions of software systems. Since the latest revision is the most 9 g12 . changeTarget ( g9 ) ;
frequently accessed revision, they store the most recent revision of Figure 3: Backward Delta between Rev_3 and Rev_2
software systems and several differences deltas for tracing back to
the earlier revisions. DL-based difference representation also fol- According to the DL syntax, each delta operation contains a
lows the similar art of delta representation in its macro-versioning Operator Part (cf. g6=createForkNode();) which describes the type of
scenario. change by means of operations (one of create, change, delete) [26]
The example depicted in Figure 2 describes the two backward and an Modeling Artifact (cf. g6=createForkNode();) (with attributes
deltas between three subsequent revisions (Rev_1, Rev_2 and if required) which refers to model element. To refer to model ele-
Rev_3). These backward deltas (Figure 3) are directed in reverse ments from the DL operations in modeling deltas, globally unique
identifiers of model elements are used as references (дx ).
Macro-versioning Designer_1
g1
g4
g2 Receive Orders
g5
Rev_1 Rev_2 Rev_3
g7 Fill Orders
g1 g1 opens
g1 g12
Micro-versioning
g4
g4
g4 g3
g2 Receive g2 Receive Order
g2 Receive Order
g5 sync
g5 g6 Designer_2
g5
g10 g11
Forward g1
g3
g7 Fill Order Deltas g4
g7 Fill Send g8
Order Invoice
g12 g2 Receive Order
g12 g13
g5
g9
g14 g3 Fill Order
opens g7
g3 g12
g15 Close Order
g16
Backward Active
Deltas Delta g3
Figure 2: Simplified UML Activity Diagram
Likewise, Figure 4 illustrates the backward modeling delta con- models in form of the modeling deltas, as well. Active deltas are
sisting of the differences between the second and first revisions. the DL-based descriptions of the base revision (working copy) of a
complete model. Active deltas consist of only creation operations.
1 g2 . changeName ( " R e c e i v e " ) ;
7 g14 . delete ( ) ; Execution of an active delta creates a complete model out of empty
2 g5 . changeTarget ( g3 ) ;
8 g6 . delete ( ) ; model.
3 g10 . delete ( ) ;
9 g7 . delete ( ) ; The third revision of the model depicted in Figure 2 is represented
4 g11 . delete ( ) ;
10 g8 . delete ( ) ; by the active delta in Figure 5 which consists of only creation oper-
5 g12 . delete ( ) ;
11 g9 . delete ( ) ; ations. When this active delta is executed on an empty model, the
6 g13 . delete ( ) ;
third, base revision of the model depicted in Figure 2 is created.
Figure 4: Backward Delta between Rev_2 and Rev_1 1 g1 = createInitialNode ( ) ;
The modeling deltas in these figures are directly executable de- 2 g2 = createOpaqueAction ( " R e c e i v e O r d e r " ) ;
scriptions of the model differences. Each of these difference deltas 3 g7 = createOpaqueAction ( " F i l l O r d e r " ) ;
allows for reverting the base model to the earlier revision from the 4 g3 = createActivityFinalNode ( ) ;
latter. The modeling delta in Figure 3 reverts the model to the sec- 5 g4 = createControlFlow ( g1 , g2 ) ;
ond revision from the third, whereas the modeling delta in Figure 4 6 g5 = createControlFlow ( g2 , g7 ) ;
reverts the same model to the first revision from the second. In 7 g12 = createControlFlow ( g7 , g3 ) ;
the DL-based modeling deltas, the unchanged modeling artifacts
Figure 5: Active Delta
are implicitly excluded simply not describing DL operations for
them. Furthermore, the modeling deltas depicted in these figures Modeling Deltas in Concurrent Collaboration. In case of
consist of further DL operations for representing changes on layout the micro-versioning scenario depicted in Figure 2, the modeling
information, as well. For the sake of simplicity, these change opera- deltas are described in the forward forms where application of the
tions are not depicted in the backward modeling deltas. However, modeling deltas to a model results in the newer revisions of the
the forward delta depicted in Figure 7 consist of DL-based change same model. There, the changes made on two parallel instances
operations for layout information. by Designer_1 and Designer_2 are represented in the forward
Active Delta. The source code-driven sequential collaborative modeling deltas. These deltas are synchronized with other parallel
systems usually store the working copy of software project and model instances in order to update these instances into the new
several (backward) deltas representing the differences between states by the change descriptions in the forward deltas. For instance,
software revisions in their software repositories. DL introduces Figure 6 depicts the forward delta consisting of the changes made
a new term active delta to store the working copies of software by Designer_1.
1 g2 . changeName ( " R e c e i v e O r d e r s " ) ;
2 g6 . changeName ( " F i l l O r d e r s " ) ; DL Generator. The DL generator generates specific DLs for
modeling languages by importing their meta-models. While gen-
Figure 6: Forward Delta of Designer_1 erating the specific DL, it inspects all concrete (i.e., non-abstract)
meta-classes of given meta-models and the attributes of these meta-
In this delta, Designer_1 changes the name of both Opaque classes.
Actions from "Receive Order" and "Fill Order" to "Receive A specific DL is always generated in form of the Model API
Orders" and "Fill Orders", respectively. This example represents including Java Interfaces and Implementations (incl. constructors)
the model revisions where their changes are not yet synchronized to recognize modeling objects, as well as Model Utility to operate
with other parallel instance of the model. on instance models. The interfaces of Model API are parameterized
In the same vein, Figure 7 depicts the forward delta representing with the elements of a given meta-model and the change opera-
the changes made by Designer_2. Unlike the previous modeling tions like create, delete, change. While generating specific DLs, the
deltas, this forward delta depicts DL operations for layout informa- creation and deletion operations are generated for each meta-class.
tion starting from line 4. There, the new nodes Location (with the It implies that model elements conforming to these meta-classes
attribute values of x, y) and Size (with the attribute values of width, can be created or deleted on instance models. The change opera-
height) are created for the newly created Opaque Action g15. On tions are generated for only meta-attributes, i.e., the attributes of
the last line, the RelativeBendpoints (with the values of the point list each modeling artifact can only be changed on instance models.
sourceX, sourceY, targetX, targetY ) of Control Flow g12 is changed. Meta-relations are associated with the attributes of meta-classes.
The DL generator considers three atomic operations create, delete
1 g15 = createOpaqueAction ( " C l o s e O r d e r " ) ; and change as the sufficient set of operations for representing all
2 g12 . changeTarget ( g15 ) ; model changes.
3 g16 = createControlFlow ( g15 , g3 ) ; The DL generator does not generate methods to modify an at-
4 g18 = createLocation ( 1 4 , 3 8 , g15 ) ; tribute that is fixed as an unique identifier. Modification of the
5 g19 = createSize ( 1 8 , 6 , g15 ) ; values of the identifier attribute (e.g., id) on the instance level is
6 g20 . changePoints ( [ 2 2 , 2 8 , 2 2 , 3 8 ] , g12 ) ; not permitted as it specifies the identity of modeling artifacts. Thus,
Figure 7: Forward Delta of Designer_2 their values should not be changed as the part of model changes.
For instance, all identifiers дx in the example in Section 4.2 are
stored using the attribute id of the class NamedElement in Figure 1.
In the concurrent collaborative modeling enabled by micro-
Collaborative Modeling Architecture. After generating a spe-
versioning, modeling deltas are represented by the DL operations in
cific DL for the given meta-model, namely the UML activity diagram
the forward forms. These forward deltas have the forward effect in
meta-model (incl. Content and Layout parts) in this case, the DL-
the models, i.e., the models are updated with the change descriptions
based collaborative modeling infrastructure can be used to handle
defined in the forward deltas. Because, the recent changes made
collaboration activities. It is built by the specific amalgamation of
by other parallel mates have to be propagated on this particular in-
the several DL services as depicted in Figure 8. It shows the refer-
stance in order to keep them up-to-date and vice verse. The forward
ence architecture for collaborative modeling including server and
deltas are rather small than backward deltas and are not stored in
client sides. The same underlying reference architecture was also
the repository. The collaborative modeling approach distinguishes
utilized in [26] to develop the Kotelett collaborative modeling
between forward and backward deltas because of their convenience
application for UML class diagrams.
for micro-versioning and macro-versioning, respectively. The for-
Server Client
ward propagation of the change operations in modeling deltas is
more practical in case of micro-versioning, whereas the backward designs UML
Repository {Models}
affect of modeling deltas to models is more convenient in macro- (Backward Deltas) Model Manager Designer
(macro-versioning) Collaborator
versioning.
These modeling deltas are represented by the specific DL for Listener detects
{Forward
Synchronizer Deltas}
changes from
UML activity diagrams generated from the meta-model depicted in (micro-versioning)
Applier applies changes to
Figure 1.
4.3 DL Services Figure 8: Reference Architecture for Collaborative Modeling
DL intends to extend its application areas by introducing several The server side consists of the synchronizer service to support
supplementary services, i.e., DL generator for generating specific micro-versioning and model manager service for macro-versioning
DLs for the given modeling languages, delta calculator for calcu- which uses the DL-based modeling delta repository. On the client
lating modeling deltas, delta applier for applying modeling deltas side, the changes made by collaborators are constantly detected by
to models, model manager for managing models and their revi- the change listener service while they are made using the model
sions, etc. As all DL services are explained in [26] in detail, this editor, in this case, UML Designer. These micro-versions are repre-
section briefly revisits the services which are involved in applying sented using forward modeling deltas and constantly sent to other
the DL-based infrastructure to design UML activity diagrams in parallel clients through the synchronizer service on the server. Once
UML Designer. These potential services are explained how they are these deltas arrive at other clients, they are applied to models by
adapted to be reusable in this section. the applier service. As long as the synchronization of modeling
deltas among clients carried out by the synchronizer on the server, collaboration. The server provides model manager feature to operate
the communication between collaborators is provided based on on that repository. For instance, new models can be created in
star-topology. the repository, existing ones can be opened by collaborators to
During collaboration, designers may store the particular state of join collaboration, existing models can be deleted, revisions can be
their models whenever they are complete and correct. Collaborators stored and loaded, etc.
are able to load models and their revisions that are saved earlier.
The macro-versioning feature is provided by the model manager
5 APPLICATION
on the server.
Listener. The change listener service is the part of the DL delta The collaborative modeling applications are developed by the spe-
calculator service. Calculation of modeling deltas depends on the cific orchestrations of the DL services explained in Section 4.3 and
scenario of collaboration whether it is macro-versioning or micro- on the top of the DL-based delta representation. This section ex-
versioning. In micro-versioning, the modeling deltas are produced plains the collaborative modeling application CoMo (Collaborative
by listening for changes in models by the change listener. Because Modeling) of DL.
changes have to be synchronized in real-time providing sufficiently The collaborative modeling application entitled CoMo is devel-
high performance. In macro-versioning, modeling deltas between oped as an extension for Sirius-based domain-specific modeling
subsequent model revisions are calculated using the state-based tool UML Designer. CoMo takes advantage of the DL-based modeling
comparison of subsequent revisions [23]. The state-based compar- deltas for synchronizing modeling deltas among the collaborators
ison and change listener are the two different features of the DL of the shared models. Figure 9 depicts a screenshot of CoMo. It
delta calculator service. displays two different tool instances working on the same model
In case of the EMF-hosted UML Designer, the listener listens concurrently. These tool instances describe the exemplary micro-
for Notifications (org.eclipse.emf.common.notify.Notification) which versioning scenario depicted in Figure 2 after the changes are syn-
consists of information about the changed model elements and the chronized. Each CoMo tool instance consists of several windows as
change types. The change types in these notifications are mapped to explained below.
the DL change types. The change types ADD, ADD_MANY are mapped Figure 9 actually depicts the modeling user interface of UML
to the create operation, REMOVE, REMOVE_MANY are mapped to Designer. As long as the DL-based collaborative modeling approach
delete, SET, UNSET are mapped to change, and MOVE is handled is applied to UML Designer which is an EMF- and Sirius-based
by the combination of the create and delete operations. The DL domain-specific modeling tool [31], CoMo is completely realized
change listener is realized using the Resource Set Listener which lis- using the EMF technical space.
tens for the Transactional Editing Domain of Sirius sessions. The use After installing the CoMo support, two buttons appear in the tool
of transactional editing domain provides to perform the redo/undo as shown on the left instance under the indicator CoMo. When the
operations without extra implementation effort. first button (Kol) is clicked, the list of models currently available in
Applier. In collaborative modeling, modeling deltas are applied the repository is displayed asking the user which model to join as
to the base models in order to transform them from one revision collaborator. From the displayed dialog window, users can either
to another. Application of modeling deltas to the base models is select an existing model from the list or create a new model in the
provided by the DL delta applier service [26]. In macro-versioning, repository. If they select to join an existing model as a collaborator,
the model manager utilizes the DL delta applier service to revert the that model is opened in the editor (D) and they can continue further
older revisions of models by applying backward deltas. In case of developing that model. The users can open multiple models at once
the loss or damage of information on the working copies of models, during collaboration.
designers may revert the earlier revisions or undo recent changes In micro-versioning, the forward modeling deltas are not stored
they made. The applier is also employed in micro-versioning in in the repository. However, reversion of changes in micro-versioning
order to propagate model changes on the concurrent instances happens on the client side of the editor and provided by the Re-
of shared models by applying forward deltas. The delta applier is do/Undo features of Transactional Command Stack. CoMo can save
further used by the model manager to load the working copies the model when the save button is clicked whenever the model is
of models by applying active deltas to empty models. Like the complete and correct. When the tool is asked to save the model
listener, the DL delta applier is adapted to be useful in the EMF by clicking the second button under the indicator CoMo, it calcu-
technical space. It converts the DL operations in modeling deltas lates the differences (backward deltas) between the last and base
to executable commands in the Recording Command. Then, these revisions. Furthermore, new active deltas are also generated when
operations are executed in the Transactional Command Stack of the new revisions of models are stored. As the result of each click,
Transactional Editing Domain of EMF. one backward delta (representing differences between base and
Synchronizer. The server side of Figure 8 depicts the DL syn- previous revisions) and one active delta (representing base working
chronizer service which allows for synchronization of micro-deltas copy) are stored in the repository. This feature of the CoMo tool is
between collaborators. Its primary task is to send modeling deltas currently under development.
to all connected clients except the sender. The synchronizer service The model tree (A) shows the list of models and diagrams (incl.
is realized using the KryoNet API [15]. the elements of these diagrams) the users are currently working
Model Manager. The repository on the server stores several on. The both instances display the modeling concepts of the UML
backward deltas and one active delta for each software model under activity diagram (B). These concepts conform to the meta-model
depicted in Figure 1. The logger window (C) constantly displays
CoMo
A D1 B D2 B
C C
E
Figure 9: CoMo Screenshot
the modeling deltas that are exchanged among collaborators once to the rapid synchronization of small modeling deltas. Thus, con-
changes are made in any instance. Creating one modeling artifact current collaborative modeling enabled by the micro-versioning
on the graphical modeling editor may result in one or many change currently does not focus on the issue of conflict resolution. In the
operations that are contained in one modeling delta that is syn- current implementations of concurrent collaborative modeling ap-
chronized between collaborators. The model editor (D1 and D2) plications, the most recent changes are propagated on all parallel
areas on the both instances show the exemplary activity diagrams instances of models.
that Designer_1 and Designer_2 are developing as depicted in For merging various model revisions in macro-versioning, the
Figure 2. In this case, these both instances are displayed after their Kotelett tool employs the existing merge technique provided by
changes are synchronized. The letter E indicates three changes the JGraLab technical space [10]. The merge technique of JGraLab
made by two designers. These changes are: the name changes from offers the semi-automated conflict resolution feature. The CoMo
"Receive Order" and "Fill Order" to "Receive Orders" and application aims at utilizing the existing EMF Diff/Merge approach
"Fill Orders" respectively (highlighted on the left logger), as [30] for model merging and conflict resolution in macro-versioning.
well as the creation of new Opaque Action named "Close Order" However, the latter is still under development.
(highlighted on the right logger).
Modeling deltas on the logger windows (C) are represented by the
specific DL generated from the combined meta-model in Figure 1 6 ADAPTABILITY
including the standard UML profiles (content part, i.e., abstract The DL-based collaborative modeling infrastructure can be adapt-
syntax) and GMF notation (layout part, i.e., concrete syntax). The able by generating specific DLs and extending the relevant DL
DL change listener and applier services are extended using EMF services.
technical space features such as the command stack and resource set • Difference Language. The approach provides the DL generator
listener extensions for the editing domains. All other underlying service for generating specific DLs. It is generic with respect to
technologies such as the DL synchronizer and model manager the meta-models of modeling languages, i.e., it is not language
remain unchanged. or tool specific. As depicted in Figure 1, the layout notation part
During experiments, the both DL applications Kotelett [27] and (above the dashed line) of the meta-models enables adaptability
CoMo have shown sufficiently high performance by synchronization of the approach for further modeling languages with the same
of small DL-based modeling deltas. So far, they have not faced any layout notation. The modeling concept part (below the dashed
change conflicts in micro-versioning. This probably is attributed line) of the meta-model should be replaced by the meta-model of
the appropriate modeling language. Eventually, the same layout [5] P. Brosch, G. Kappel, M. Seidl, K. Wieland, M. Wimmer, H. Kargl, and P. Langer.
information can be reused for further modeling languages. 2010. Adaptable Model Versioning in Action. in: Proc. Modellierung 2010, Klagen-
furt, Austria LNI 161 (March 24-26 2010), 221–236.
• DL Services. The DL services are developed by following the [6] A. Cicchetti, D. Di Ruscio, and A. Pierantonio. 2007. A Metamodel independent
service-oriented development principles. This allows to extend approach to difference representation. journal of Object Technology 6:9 (October
2007), 165–185.
and adapt each independent service without affecting the rest of [7] Cinergix Pty. visited on 22.07.2018. CreateLy. http://www.creately.com.
the underlying concepts and technologies of collaborative mod- [8] B. Collins-Sussman, B. Fitzpatrick, and M. Pilato. 2004. Version Control with
eling. This enables tool developers to develop further services or Subversion. O’Reilly Media (June 2004).
[9] M. Dirix, A. Muller, and V. Aranega. 2013. GenMyModel: UML case tool. In
adapt the existing ones as they want, and reuse the collaborative ECOOP.
modeling environment without any further development effort. [10] J. Ebert, V. Riediger, and A. Winter. 2008. Graph technology in reverse engineering.
The DL services can also be replaced by other implementations The TGraph approach. In Proc. 10th Workshop Software Reengineering. GI Lecture
Notes in Informatics. Citeseer, 23–24.
and extended with additional features. The only prerequisite [11] Eclipse Foundation. visited on 22.07.2018. Sirius. Project website:
for these services is to recognize the syntax of DL. Eventually, https://www.eclipse.org/sirius/.
[12] Eclipse Foundation, Project Web site. visited on 22.07.2018. Graphical Modeling
these services can again be involved in service orchestrations Project (GMP). http://www.eclipse.org/modeling/gmp/.
for establishing the collaborative modeling applications. [13] Eclipse Project Website. visited on 22.07.2018. EMF-based Model Repository:
• DL Applications. The DL applications, former Kotelett and cur- Corrected Data Objects (CDO). http://eclipse.org/cdo.
[14] C. Ellis, G. Simon, and R. Gail. 1991. Groupware: Some Issues and Experiences.
rent CoMo, are developed based on the same underlying reference ACM 34, 1 (1991), 39–58.
architecture depicted in Figure 8. The DL services are orches- [15] Esoteric Software. visited on 22.07.2018. KryoNet.
trated according to this reference architecture to develop the https://github.com/EsotericSoftware/kryonet.
[16] Firebase Inc. visited on 07.07.2018. Firepad. https://firepad.io.
aforementioned DL applications. The same underlying reference [17] M. Fluegge. 2009. Entwicklung einer kollaborativen Erweiterung fuer GMF-
architecture can be adapted and serve as a common blueprint Editoren auf Basis modellgetriebener und webbasierter Technologien. Master’s
thesis, University of Applied Sciences Berlin (2009). http://wiki.eclipse.org/Dawn
for developing collaborative modeling environments for any [18] M. Franzago, D. D. Ruscio, I. Malavolta, and H. Muccini. 2017. Collaborative
(EMF-based) open source tools with lesser development effort. Model-Driven Software Engineering: a Classification Framework and a Research
Map. IEEE Transactions on Software Engineering (September 2017). https://doi.
org/10.1109/TSE.2017.2755039
7 CONCLUSION [19] Google Inc. visited on 07.07.2018. Google Docs. http://docs.google.com.
[20] J. Helming and M. Koegel. last accessed on 22.07.2018. EMFStore. Project web
A meta-model generic DL introduced in [26] is applied to UML class site. http://eclipse.org/emfstore.
diagrams in [27], which resulted in the Kotelett tool. To demonstrate [21] J. Herbsleb and D. Moitra. 2001. Global software development. IEEE software 18,
2 (2001), 16–20.
applicability of the DL-based collaborative modeling infrastructure, [22] T. Kehrer, U. Kelter, M. Ohrndorf, and T. Sollbach. 2012. Understanding model
it is applied to UML Designer which resulted in the CoMo tool in this evolution through semantically lifting model differences with SiLift. In Software
Maintenance (ICSM), 2012 28th IEEE International Conference on. IEEE, 638–641.
paper. DL is aware of both content (i.e., abstract syntax) and layout [23] T. Kehrer, M. Rindt, P. Pietsch, and U. Kelter. 2013. Generating Edit Operations
(i.e., concrete syntax) of modeling languages and provides sequen- for Profiled UML Models. In MoDELS. 30–39.
tial and concurrent collaborative modeling support, simultaneously. [24] A. Kleppe, J. Warmer, and W. Bast. 2003. MDA Explained: The Model Driven
Architecture: Practice and Promise. Addison-Wesley Longman Publishing Co., Inc.,
The proposed DL serves as a common change representation and Boston, MA, USA.
exchange format for storing and synchronizing model changes [25] D. Kuryazov and A. Winter. 2014. Representing Model Differences by Delta
between the subsequent and concurrent revisions of evolving mod- Operations. In 18th International Enterprise Distributed Object Oriented Computing
Conference, Worshops and Demonstrations (EDOCW), IEEE Computer Society Press,
els. The both sequential and concurrent collaborative modeling 2014, ISBN 978-1-4799-5467-4, Manfred Reichert, Stefanie Rinderle-Ma, and Georg
rely on the same base difference representation language (DL) for Grossmann (Eds.). Ulm, Germany, 211–220.
[26] D. Kuryazov and A. Winter. 2015. Collaborative Modeling Empowered By Mod-
representing modeling deltas. eling Deltas. In Proceedings of the 3rd International Workshop on (Document)
There are several EMF-based domain-specific modeling editors Changes: modeling, detection, storage and visualization. ACM, 1–6.
that can be used as a model designing tool for various modeling lan- [27] D. Kuryazov, A. Winter, and R. Reussner. 2018. Collaborative Modeling Enabled
by Version Control. In Modellierung 2018, Ina Schaefer, Dimitris Karagiannis,
guages. However, they either lack collaborative modeling features and Andreas Vogelsang (Eds.), Vol. P-280. Gesellschaft für Informatik (GI), Bonn,
or provide commercial solutions. They usually require open-source 183–198. ISBN: 978-3-88579-674-9.
and operational collaborative modeling features with model reposi- [28] M. Mackall. 2010. The Mercurial SCM. Internet Website, last accessed 05.07.2018
(2010).
tories as a single point of truth. Thereby, the DL-based collaborative [29] E. W. Myers. 1986. An O (ND) difference algorithm and its variations. Algorithmica
modeling infrastructure with its difference representation, services 1, 1 (1986), 251–266.
[30] O. Constant. visited on 22.07.2018. EMF Diff/Merge, Project Website.
and reference architecture can be adapted and utilized for collabo- http://eclipse.org/diffmerge/.
rative MDE. [31] Obeo Network. visited on 22.07.2018. UML Designer. Project website:
http://www.umldesigner.org.
[32] J. Raumbaugh, I. Jacobson, and G. Booch. 2004. Unified Modeling Language
REFERENCES Reference Manual. Pearson Higher Education.
[33] C. Seidl, I. Schaefer, and U. Aßmann. 2014. DeltaEcore-A Model-Based Delta
[1] A. Schmidt et al. 2011. visited on 22.07.2018. emfCollab: Collaborative Editing Language Generation Framework. In Modellierung 2014. 81–96.
for EMF models. http://qgears.com/products/emfcollab/. [34] D. Steinberg, F. Budinsky, E. Merks, and M. Paternostro. 2008. EMF: Eclipse
[2] M. Alanen and I. Porres. 2003. Difference and Union of Models. In P.Stevens, Modeling Framework. Addison-Wesley Longman Publishing Co., Inc.
J.Whittle, and G. Booch, editors, Proc. 6th Int. Conf. on the UML, Springer LNCS [35] T. Swicegood. 2008. Pragmatic version control using Git. Pragmatic Bookshelf.
2863 (2003), 2–17. [36] G. Taentzer, C. Ermel, P. Langer, and M. Wimmer. 2012. A fundamental approach
[3] K. Altmanninger, A. Bergmayr, W. Schwinger, and G. Kotsis. 2007. Semantically to model versioning based on graph modifications: from theory to implementa-
enhanced conflict detection between model versions in SMoVer by example. In tion. journal: Software and Systems Modeling (April 25 2012).
Procs of the Int. Workshop on Semantic-Based Software Development at OOPSLA.
[4] AppJet Inc. visited on 22.02.2018. Etherpad. Project Web Site:
http://www.etherpad.com.