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.