Model-Driven Engineering has already become a significant means in software development activities, which is well-suited to design and develop large-scale software systems. Developing and maintaining large-scale model-driven software systems entails a need for collaborative modeling by a large number of software designers and developers. As the first-class entities of the model-driven engineering paradigm, software models are constantly changed during development and maintenance. Collaborative modeling support for frequently synchronizing model changes between collaborators is required. Thereby, a solid change representation support for model changes plays an essential role for collaborative modeling systems. This paper applies a meta-model generic, operation-based and textual diference language to existing domain-specific modeling tool UML Designer and demonstrates a collaborative modeling application - CoMo. It is validated for UML activity diagrams.
Model-Driven Engineering (MDE) has become a popular means for software development which supports appropriate abstraction concepts to software development activities. It aims at improving the productivity of software development, maintenance activities, and communication among various teams and stakeholders. In MDE, software models are the first-class artifacts of software development rather than the source code implementing the systems. This leads to the several main benefits of MDE: the productivity boost, models become a single point of truth and are automatically kept up-to-date with the code they specify [24, pp. 9f].
Software models (e.g. in UML – Unified Modeling Language [
Like the source code of software systems, software models are constantly evolved and maintained in order to cope with various user changes such as improvements, extensions, and optimization. All development and maintenance activities contribute to the evolution of software models. These activities may include creating new artifacts, removing existing ones, or/and changing the attributes of existing artifacts. Any type of the aforementioned changes that may occur during development and evolution of software models are referred to as model changes.
Development and maintenance of software models requires a
need for collaborative modeling of several collaborators like
managers, designers, developers, testers, and maintainers in order to
accomplish successful results [
Depending on the nature of interaction, collaborative
modeling can be divided into two main forms, namely concurrent and
sequential collaborative modeling [
In both micro- and macro-versioning scenarios, modeling deltas are the first-class entities and play an essential role in synchronizing the small model changes between the parallel instances of models, storing/representing model changes in eficient ways, and managing models and their revisions. The both collaborative modeling scenarios might rely on the same underlying change representation approach to deal with modeling deltas. Therefore, the eficient representation of modeling deltas is crucial for both scenarios.
A meta-model generic, operation-based and textual change
representation approach entitled Diference Language (DL) for
representing modeling deltas in both micro- and macro-versioning was
introduced in [
The remainder of this paper is structured as follows: Section 2 investigates existing related approaches in the research domain. Several characteristics of DL and its collaborative modeling application are defined in Section 3. The core concepts behind the DL-based collaborative modeling are depicted in Section 4 and the same section explains the subset of services provided by DL. Section 5 explains the CoMo collaborative modeling application of DL. Section 6 discusses adaptability and extendability of the DL-based collaborative modeling application. This paper ends up in Section 7 by drawing some conclusions. 2
The problem of collaborative modeling and its change representation is the actively discussed and extensively addressed topic among the research community of software engineering. There is a large number of research papers addressing to collaborative modeling (Section 2.1) and model diference/change representation (Section 2.2). 2.1
This section briefly reviews some collaborative development, document editing and modeling approaches in order to derive some general concepts and principals.
Concurrent collaboration systems record and synchronize change
notifications during collaborative development. Collaborative
document writing systems like Google Docs [
Sequential collaboration systems such as Git [
For diferentiating revisions and calculating diferences, most
of the collaborative systems for source code-driven software
development use the Myer’s LCS [
As long as modeling delta representation is a decisively significant issue in developing collaborative environments, this section briefly reviews and classifies some delta representation approaches. The existing collaborative modeling approaches employ various techniques for model change representation in modeling deltas. Below, the existing approaches are classified and discussed according to their diference/change representation techniques.
The most approaches identify themselves as the operation-based diference representation. They usually use basic edit operations such as create, delete and change (or similar and more), which is a general concept being relevant to many diference representation approaches. Regardless of their diference representation techniques, they employ these basic operations only for recognizing the types of model changes, but information about model changes is generally stored in various forms as discussed below.
Model-based approaches represent modeling deltas using models.
Cicchetti et al. [
Graph-based approaches represent model changes using internal
graph-like structures. It is usually similar to model-based
representation, but relying on the low-level graph-like structures. A generic
approach to model diference calculation and representation using
edit scripts is introduced in the SiDif approach [
Relational Database-based approaches represent model changes
in classical relational databases. Likely, SMOVER [
Text-based approaches represent model changes in modeling
deltas by a sequence of edit operations in the textual forms
embedding change-related diference information. An early text-based
representation approach is introduced by Alanen and Porres [
This section discusses the existing related approaches based on the criteria if representation by these approaches can provide small modeling deltas for both sequential and concurrent collaborative modeling. Besides, there are several approaches focusing only on some aspects of these collaborative modeling, and are not discussed in this paper.
The graph- and model-based representations of modeling deltas are more efective in case of the sequential collaboration and distributed concurrent collaboration. The modeling deltas represented by models or graphs usually consist of additional conceptual information for representing its modeling or graph concepts alongside actual change information. Thus, the model- and graph-based modeling deltas might not be as small (micro) as text-based modeling deltas. Modeling deltas have to be as small as possible to achieve higher performance (by rapid synchronization of modeling deltas) in concurrent collaborative modeling in real-time. During the evolutionary life-cycle, if all diference information is stored in a database, the database might become complex and large with an associated data set. Thus, the database-based representation approaches may require more implementation efort in identification and reuse of modeling deltas.
Modeling deltas represented in textual forms are the most likely to be small, especially well-suited to concurrent collaboration scenario. The textual modeling deltas are (1) directly executable descriptions of model changes; (2) easy to implement; (3) expressive, yet unambiguous providing necessary knowledge; (4) easy to synchronize with high performance; (5) easy serialization and deserialization by textual parser.
Literature review shows that research on modeling delta representation for collaborative modeling is still in its infancy. Considering the aforementioned discussions, this paper requests a textual diference language (DL) to represent modeling deltas in sequential and concurrent collaborative modeling. 3
A meta-model generic, operation-based and textual Diference
Language (DL) for representing modeling deltas in both micro- and
macro-versioning was introduced in [
Several requirements operation-based, meta-model generic, tool
independent, delta-based, completeness, reusability for DL and its
services are described and fulfilled in [
Since there are already several advanced domain-specific model
designing tools, this paper applies the DL-based collaborative
modeling infrastructure to Sirius-based [
Meta-model. DL is conceptually a family of domain-specific languages and generic with respect to the meta-models of modeling languages. As long as the modeling concepts of any modeling language can be recognized by looking at the meta-models of these languages, specific DLs for particular modeling languages are generated by importing their meta-models. Therefore, DL requires the meta-model of a modeling language, in this particular case, the meta-model of UML activity diagrams. DL supports the following characteristics to apply the DL-based collaborative modeling infrastructure to the modeling language: • DL Generation. In order to apply the DL-based collaborative modeling infrastructure to a particular domain-specific language which is defined by its appropriate meta-model, the DL generator service (Section 4.3) generates a specific DL from the meta-model of a potential modeling language, UML activity diagram. Then, the modeling deltas can be represented in terms of DL on the instance models conforming to that modeling language. • Service Adaptation. DL supports several potential supplementary services (Section 4.3) for extending the application areas of DL. These services are capable of operating on the DL-based modeling deltas, e.g., calculating, applying, synchronizing, and managing modeling deltas. For applying the DL-based collaborative modeling infrastructure to domain-specific tool UML designer, delta calculator and delta applier services have to be adapted. The other services remain unchanged.
These characteristic are addressed in Section 4 to apply the DLbased collaborative modeling infrastructure to design UML activity diagrams in the UML Designer tool. 4
The DL-based collaborative modeling infrastructure considers model changes as the first-class entities for supporting concurrent collaboration by micro-versioning and sequential collaboration by macroversioning. Thus, first of all, DL aims at representing model changes in modeling deltas in eficient ways.
DL is conceptually a family of domain-specific languages for representing model changes. A specific DL is derived from the metamodel of a modeling language. Since this paper applies the DL-based collaborative modeling infrastructure to designing UML activity diagrams in UML Designer, the approach requests the meta-model of activity diagram as initial prerequisite to generate a specific DL. Thereafter, the relevant DL services have to be adapted to be capable of handling new modeling languages in the new model designing tool.
Section 4.1 depicts the substructure of the UML activity diagram meta-model. Section 4.2 exemplifies a simplified running example for the DL-based change representation. Section 4.3 explains a subset of supplementary DL services required for applying collaborative modeling and how they are adapted to be handy in this particular case. 4.1
The modeling concepts of any modeling language can be recognized by inspecting the meta-model of that language. Thus, a specific DL for UML activity diagram is generated by the DL generator service (explained in Section 4.3) importing the UML activity diagram meta-model. Then, the model changes in modeling deltas can be represented in terms of DL on the instance activity diagrams. However, the DL generator is generic with respect to the meta-models of modeling languages.
Figure 1 depicts the substructure of the UML activity diagram
meta-model that is used throughout this section as a running
example. The meta-model is separated into two parts by a dashed line.
Below the line, it depicts the content part (i.e., abstract syntax) which
is adapted from the standard UML activity diagram meta-model for
EMF (Eclipse Modeling Framework) [
This way of designing meta-models allows for using the same collaborative modeling environment for diferent modeling contents. The complete meta-model is used for creating overall collaborative modeling application explained in Section 5. 4.2
In order to express how DL is applied to change representation 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 apply the DL approach. Figure 2 depicts three subsequent revisions namely Rev_1, Rev_2 and Rev_3 of the same UML activity diagram describing an "Ordering System" example. All model revisions conform to the same meta-model shown in Figure 1. Figure 2 further depicts two concurrent copies of the latest revision, in this case, Rev_3. Two designers, namely Designer_1 and Designer_2 are working on these parallel copies.
Globally Unique Identifiers. According to the NamedElement class of the meta-model in Figure 1, each modeling artifact has an attribute named id. In order to identify modeling artifacts and to represent referenced changes in modeling deltas, this identifier attribute is used in modeling delta operations. Assigning modeling artifacts to globally unique identifiers allows to identify and keep track of the modeling artifacts of evolving software models over time. With unique identifiers, inter-delta (i.e., predecessor and successor) and delta-model references can easily be detected. The inter-delta references allow for tracing any particular modeling artifact by detecting the predecessor and successor artifacts of an initial modeling artifact. The delta-model references are used to refer to modeling artifacts from modeling deltas in applying modeling deltas to software models by the DL applier service (explained in Section 4.3).
Model Changes. In the first revision, the model consists of one Opaque Action named "Receive" as well as Initial Node and Final Node. All modeling artifacts are connected by Control Flows. While evolving from the first revision to the second, the following changes are made on the model: Fork Node, Join Node, two Opaque Actions named "Fill Order" and "Send Invoice" are created, the target end of the control flow g5 is reconnected to the Fork Node, the name of the Opaque Action g2 is changed, and several control flows are created connecting these nodes. The model again evolves into the third revision Rev_3 after making the following changes: the target end of the control flow g5 is reconnected to the Opaque Action g7, the target end of the control flow g12 is reconnected to the Activity Final Node. The nodes Fork Node, Join Node, Opaque Action "g8" and the control flows g10, g11, g13, g14 are deleted.
In the third, last revision, the model is then being further developed by two designers concurrently. Designer_1 changes the names of the Opaque Actions g2 and g7 from "Receive Order" and "Fill Order" to "Receive Orders" and "Fill Orders", respectively. These changes are then sent to the other instance in form of the DL-based modeling delta (Figure 6). On the other instance, Designer_2 creates a new Opaque Action named "Close Order". The same designer creates one Control Flow g16 and reconnects the target end of the control flow g12 from the Activity Final Node 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 modeling delta (Figure 7).
Modeling Deltas in Sequential Collaboration. In sequential
collaboration (cf. Subversion [
The example depicted in Figure 2 describes the two backward
deltas between three subsequent revisions (Rev_1, Rev_2 and
Rev_3). These backward deltas (Figure 3) are directed in reverse
order, i.e., application of the backward deltas to models transforms
models into the earlier revisions. For instance, application of the
backward delta in Figure 3 to Rev_3 results in Rev_2.
1 g6= createForkNode ( ) ;
2 g8= createOpaqueAction ( " Send I n v o i c e " ) ;
3 g9= createJoinNode ( ) ;
4 g10 = createControlFlow ( g6 , g7 ) ;
5 g11 = createControlFlow ( g6 , g8 ) ;
6 g13 = createControlFlow ( g8 , g9 ) ;
7 g14 = createControlFlow ( g9 , g3 ) ;
8 g5 . changeTarget ( g6 ) ;
9 g12 . changeTarget ( g9 ) ;
According to the DL syntax, each delta operation contains a
Operator Part (cf. g6=createForkNode();) which describes the type of
change by means of operations (one of create, change, delete) [
g5 Rev_2
Likewise, Figure 4 illustrates the backward modeling delta consisting of the diferences between the second and first revisions. 1 g2 . changeName ( " R e c e i v e " ) ; 2 g5 . changeTarget ( g3 ) ; 3 g10 . delete ( ) ; 4 g11 . delete ( ) ; 5 g12 . delete ( ) ; 6 g13 . delete ( ) ; 7 g14 . delete ( ) ; 8 g6 . delete ( ) ; 9 g7 . delete ( ) ; 10 g8 . delete ( ) ; 11 g9 . delete ( ) ; The modeling deltas in these figures are directly executable descriptions of the model diferences. Each of these diference deltas allows for reverting the base model to the earlier revision from the latter. The modeling delta in Figure 3 reverts the model to the second revision from the third, whereas the modeling delta in Figure 4 reverts the same model to the first revision from the second. In the DL-based modeling deltas, the unchanged modeling artifacts are implicitly excluded simply not describing DL operations for them. Furthermore, the modeling deltas depicted in these figures consist of further DL operations for representing changes on layout information, as well. For the sake of simplicity, these change operations are not depicted in the backward modeling deltas. However, the forward delta depicted in Figure 7 consist of DL-based change operations for layout information.
Active Delta. The source code-driven sequential collaborative systems usually store the working copy of software project and several (backward) deltas representing the diferences between software revisions in their software repositories. DL introduces a new term active delta to store the working copies of software models in form of the modeling deltas, as well. Active deltas are the DL-based descriptions of the base revision (working copy) of a complete model. Active deltas consist of only creation operations. Execution of an active delta creates a complete model out of empty model.
The third revision of the model depicted in Figure 2 is represented by the active delta in Figure 5 which consists of only creation operations. When this active delta is executed on an empty model, the third, base revision of the model depicted in Figure 2 is created. 1 g1= createInitialNode ( ) ; 2 g2= createOpaqueAction ( " R e c e i v e Order " ) ; 3 g7= createOpaqueAction ( " F i l l Order " ) ; 4 g3= createActivityFinalNode ( ) ; 5 g4= createControlFlow ( g1 , g2 ) ; 6 g5= createControlFlow ( g2 , g7 ) ; 7 g12 = createControlFlow ( g7 , g3 ) ;
Modeling Deltas in Concurrent Collaboration. In case of the micro-versioning scenario depicted in Figure 2, the modeling deltas are described in the forward forms where application of the modeling deltas to a model results in the newer revisions of the same model. There, the changes made on two parallel instances by Designer_1 and Designer_2 are represented in the forward modeling deltas. These deltas are synchronized with other parallel model instances in order to update these instances into the new states by the change descriptions in the forward deltas. For instance, Figure 6 depicts the forward delta consisting of the changes made by Designer_1.
In this delta, Designer_1 changes the name of both Opaque Actions from "Receive Order" and "Fill Order" to "Receive Orders" and "Fill Orders", respectively. This example represents the model revisions where their changes are not yet synchronized with other parallel instance of the model.
In the same vein, Figure 7 depicts the forward delta representing the changes made by Designer_2. Unlike the previous modeling deltas, this forward delta depicts DL operations for layout information starting from line 4. There, the new nodes Location (with the attribute values of x, y) and Size (with the attribute values of width, height) are created for the newly created Opaque Action g15. On the last line, the RelativeBendpoints (with the values of the point list sourceX, sourceY, targetX, targetY ) of Control Flow g12 is changed.
In the concurrent collaborative modeling enabled by microversioning, modeling deltas are represented by the DL operations in the forward forms. These forward deltas have the forward efect in the models, i.e., the models are updated with the change descriptions defined in the forward deltas. Because, the recent changes made by other parallel mates have to be propagated on this particular instance in order to keep them up-to-date and vice verse. The forward deltas are rather small than backward deltas and are not stored in the repository. The collaborative modeling approach distinguishes between forward and backward deltas because of their convenience for micro-versioning and macro-versioning, respectively. The forward propagation of the change operations in modeling deltas is more practical in case of micro-versioning, whereas the backward afect of modeling deltas to models is more convenient in macroversioning.
These modeling deltas are represented by the specific DL for UML activity diagrams generated from the meta-model depicted in Figure 1. 4.3
DL intends to extend its application areas by introducing several
supplementary services, i.e., DL generator for generating specific
DLs for the given modeling languages, delta calculator for
calculating modeling deltas, delta applier for applying modeling deltas
to models, model manager for managing models and their
revisions, etc. As all DL services are explained in [
DL Generator. The DL generator generates specific DLs for modeling languages by importing their meta-models. While generating the specific DL, it inspects all concrete (i.e., non-abstract) meta-classes of given meta-models and the attributes of these metaclasses.
A specific DL is always generated in form of the Model API including Java Interfaces and Implementations (incl. constructors) to recognize modeling objects, as well as Model Utility to operate on instance models. The interfaces of Model API are parameterized with the elements of a given meta-model and the change operations like create, delete, change. While generating specific DLs, the creation and deletion operations are generated for each meta-class. It implies that model elements conforming to these meta-classes can be created or deleted on instance models. The change operations are generated for only meta-attributes, i.e., the attributes of each modeling artifact can only be changed on instance models. Meta-relations are associated with the attributes of meta-classes. The DL generator considers three atomic operations create, delete and change as the suficient set of operations for representing all model changes.
The DL generator does not generate methods to modify an attribute that is fixed as an unique identifier. Modification of the values of the identifier attribute (e.g., id) on the instance level is not permitted as it specifies the identity of modeling artifacts. Thus, 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.
Collaborative Modeling Architecture. After generating a
specific DL for the given meta-model, namely the UML activity diagram
meta-model (incl. Content and Layout parts) in this case, the
DLbased collaborative modeling infrastructure can be used to handle
collaboration activities. It is built by the specific amalgamation of
the several DL services as depicted in Figure 8. It shows the
reference architecture for collaborative modeling including server and
client sides. The same underlying reference architecture was also
utilized in [
Server
Model Manager (macro-versioning) Synchronizer (micro-versioning) {Models} {Forward Deltas}
Collaborator Listener Applier
Client designs
UML Designer detects changes from applies changes to
Repository (Backward Deltas)
The server side consists of the synchronizer service to support micro-versioning and model manager service for macro-versioning which uses the DL-based modeling delta repository. On the client side, the changes made by collaborators are constantly detected by the change listener service while they are made using the model editor, in this case, UML Designer. These micro-versions are represented using forward modeling deltas and constantly sent to other parallel clients through the synchronizer service on the server. Once these deltas arrive at other clients, they are applied to models by the applier service. As long as the synchronization of modeling deltas among clients carried out by the synchronizer on the server, the communication between collaborators is provided based on star-topology.
During collaboration, designers may store the particular state of their models whenever they are complete and correct. Collaborators are able to load models and their revisions that are saved earlier. The macro-versioning feature is provided by the model manager on the server.
Listener. The change listener service is the part of the DL delta
calculator service. Calculation of modeling deltas depends on the
scenario of collaboration whether it is macro-versioning or
microversioning. In micro-versioning, the modeling deltas are produced
by listening for changes in models by the change listener. Because
changes have to be synchronized in real-time providing suficiently
high performance. In macro-versioning, modeling deltas between
subsequent model revisions are calculated using the state-based
comparison of subsequent revisions [
In case of the EMF-hosted UML Designer, the listener listens for Notifications (org.eclipse.emf.common.notify.Notification) which consists of information about the changed model elements and the change types. The change types in these notifications are mapped to the DL change types. The change types ADD, ADD_MANY are mapped to the create operation, REMOVE, REMOVE_MANY are mapped to delete, SET, UNSET are mapped to change, and MOVE is handled by the combination of the create and delete operations. The DL change listener is realized using the Resource Set Listener which listens for the Transactional Editing Domain of Sirius sessions. The use of transactional editing domain provides to perform the redo/undo operations without extra implementation efort.
Applier. In collaborative modeling, modeling deltas are applied
to the base models in order to transform them from one revision
to another. Application of modeling deltas to the base models is
provided by the DL delta applier service [
Synchronizer. The server side of Figure 8 depicts the DL
synchronizer service which allows for synchronization of micro-deltas
between collaborators. Its primary task is to send modeling deltas
to all connected clients except the sender. The synchronizer service
is realized using the KryoNet API [
Model Manager. The repository on the server stores several backward deltas and one active delta for each software model under collaboration. The server provides model manager feature to operate on that repository. For instance, new models can be created in the repository, existing ones can be opened by collaborators to join collaboration, existing models can be deleted, revisions can be stored and loaded, etc. 5
The collaborative modeling applications are developed by the specific orchestrations of the DL services explained in Section 4.3 and on the top of the DL-based delta representation. This section explains the collaborative modeling application CoMo (Collaborative Modeling) of DL.
The collaborative modeling application entitled CoMo is developed as an extension for Sirius-based domain-specific modeling tool UML Designer. CoMo takes advantage of the DL-based modeling deltas for synchronizing modeling deltas among the collaborators of the shared models. Figure 9 depicts a screenshot of CoMo. It displays two diferent tool instances working on the same model concurrently. These tool instances describe the exemplary microversioning scenario depicted in Figure 2 after the changes are synchronized. Each CoMo tool instance consists of several windows as explained below.
Figure 9 actually depicts the modeling user interface of UML
Designer. As long as the DL-based collaborative modeling approach
is applied to UML Designer which is an EMF- and Sirius-based
domain-specific modeling tool [
After installing the CoMo support, two buttons appear in the tool as shown on the left instance under the indicator CoMo. When the ifrst button ( Kol) is clicked, the list of models currently available in the repository is displayed asking the user which model to join as collaborator. From the displayed dialog window, users can either select an existing model from the list or create a new model in the repository. If they select to join an existing model as a collaborator, that model is opened in the editor (D) and they can continue further developing that model. The users can open multiple models at once during collaboration.
In micro-versioning, the forward modeling deltas are not stored in the repository. However, reversion of changes in micro-versioning happens on the client side of the editor and provided by the Redo/Undo features of Transactional Command Stack. CoMo can save the model when the save button is clicked whenever the model is complete and correct. When the tool is asked to save the model by clicking the second button under the indicator CoMo, it calculates the diferences (backward deltas) between the last and base revisions. Furthermore, new active deltas are also generated when the new revisions of models are stored. As the result of each click, one backward delta (representing diferences between base and previous revisions) and one active delta (representing base working copy) are stored in the repository. This feature of the CoMo tool is currently under development.
The model tree (A) shows the list of models and diagrams (incl. the elements of these diagrams) the users are currently working on. The both instances display the modeling concepts of the UML activity diagram (B). These concepts conform to the meta-model depicted in Figure 1. The logger window (C) constantly displays D1
B
D2 C
E B C the modeling deltas that are exchanged among collaborators once changes are made in any instance. Creating one modeling artifact on the graphical modeling editor may result in one or many change operations that are contained in one modeling delta that is synchronized between collaborators. The model editor (D1 and D2) areas on the both instances show the exemplary activity diagrams that Designer_1 and Designer_2 are developing as depicted in Figure 2. In this case, these both instances are displayed after their changes are synchronized. The letter E indicates three changes made by two designers. These changes are: the name changes from "Receive Order" and "Fill Order" to "Receive Orders" and "Fill Orders" respectively (highlighted on the left logger), as well as the creation of new Opaque Action named "Close Order" (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 including the standard UML profiles (content part, i.e., abstract syntax) and GMF notation (layout part, i.e., concrete syntax). The DL change listener and applier services are extended using EMF technical space features such as the command stack and resource set listener extensions for the editing domains. All other underlying technologies such as the DL synchronizer and model manager remain unchanged.
During experiments, the both DL applications Kotelett [
For merging various model revisions in macro-versioning, the
Kotelett tool employs the existing merge technique provided by
the JGraLab technical space [
The DL-based collaborative modeling infrastructure can be adaptable by generating specific DLs and extending the relevant DL services. • Diference Language. The approach provides the DL generator service for generating specific DLs. It is generic with respect to the meta-models of modeling languages, i.e., it is not language or tool specific. As depicted in Figure 1, the layout notation part (above the dashed line) of the meta-models enables adaptability of the approach for further modeling languages with the same layout notation. The modeling concept part (below the dashed line) of the meta-model should be replaced by the meta-model of the appropriate modeling language. Eventually, the same layout information can be reused for further modeling languages. • DL Services. The DL services are developed by following the service-oriented development principles. This allows to extend and adapt each independent service without afecting the rest of the underlying concepts and technologies of collaborative modeling. This enables tool developers to develop further services or adapt the existing ones as they want, and reuse the collaborative modeling environment without any further development efort. The DL services can also be replaced by other implementations and extended with additional features. The only prerequisite for these services is to recognize the syntax of DL. Eventually, these services can again be involved in service orchestrations for establishing the collaborative modeling applications. • DL Applications. The DL applications, former Kotelett and current CoMo, are developed based on the same underlying reference architecture depicted in Figure 8. The DL services are orchestrated according to this reference architecture to develop the aforementioned DL applications. The same underlying reference architecture can be adapted and serve as a common blueprint for developing collaborative modeling environments for any (EMF-based) open source tools with lesser development efort. 7
A meta-model generic DL introduced in [
There are several EMF-based domain-specific modeling editors that can be used as a model designing tool for various modeling languages. However, they either lack collaborative modeling features or provide commercial solutions. They usually require open-source and operational collaborative modeling features with model repositories as a single point of truth. Thereby, the DL-based collaborative modeling infrastructure with its diference representation, services and reference architecture can be adapted and utilized for collaborative MDE.